Skip to content

Practice Exercise: Testing a Working Site hosted in a CDN

Objectives

The objective of this lab exercise is to have interns to understand how CDN works and how it improves site access time by caching important resources.

Prerequisites

  • You must have a SSH/terminal access to your web1 instance: <name>-a1t-inf-ds-web1.acad.opswerks.net.

Exercises

You will be simulating accessing a static website that's hosted in a Content Delivery Network (CDN). We're going to compare accessing the CDN endpoint called the "edge" and the actual actual web servers, which in CDN terms is an "origin".

In this setup, the two web servers (origin) are situated in the Oregon (US West Coast) and Singapore, having 1 node each. They are controlled infront by a CDN distribution with the hostname ds-edge.opswerks.net.

Exercise Setup

Exercise 1: Accessing the Website

Step 1: SSH to your web1 instance <name>-a1t-inf-ds-web1.acad.opswerks.net. Step 2: Access our static websites in both the Oregon (US West) and Singapore. Let's time the access so you can see how long it takes to load the site.

Hint: You can easily time the execution of a Linux by prepending the time command at the start of the whole command block.

Oregon:

$ time curl http://ds-bucket-uw2.s3-website-us-west-2.amazonaws.com
<h1> <p style="font-family:system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, 'Open Sans', 'Helvetica Neue', sans-serif">Hi! I'm a Website running in Oregon, USA! </h1>
</p>
real    0m0.130s
user    0m0.007s
sys     0m0.000s

Singapore:

$ time curl http://ds-bucket-sg.s3-website-ap-southeast-1.amazonaws.com
<h1> <p style="font-family:system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, 'Open Sans', 'Helvetica Neue', sans-serif">Hi! I'm a Website running in Singapore! </h1>
</p>
real    0m0.453s
user    0m0.005s
sys     0m0.005s

You will see the time it took to process the curl request. Note the loading time for both the US West and Singapore websites.

Step 3: Now let's try accessing the website through the hosted CDN distribution endpoint. The endpoint is normally called the "edge".

time curl https://ds-edge.sandbox.opswerks.net
<h1> <p style="font-family:system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, 'Open Sans', 'Helvetica Neue', sans-serif">Hi! I'm a Website running in Oregon, USA! </h1>
</p>
real    0m0.073s
user    0m0.038s
sys     0m0.007s

Step 4: Take note of the site loading time through the CDN. Also take note of the output of the HTML page. It will say where it's running. On your test, where is it running?

Step 5: Try hitting the CDN edge again a couple of times. Did the load time improve? What was the output of the webpage that you got, is it the Oregon (US West) or the Singapore one?

Exercise 2: Downloading a Big File

Step 6: Now let's test again by timing the download of a slightly larger file. This is an image worth 8.5MB.

Oregon:

time wget http://ds-bucket-uw2.s3-website-us-west-2.amazonaws.com/BigFileSample.png

Singapore:

time wget http://ds-bucket-sg.s3-website-ap-southeast-1.amazonaws.com/BigFileSample.png

Step 7: Now, let's try downloading it from the CDN endpoint:

time wget https://ds-edge.sandbox.opswerks.net/BigFileSample.png

Step 8: Take note of the time of the initial download. Now, hit the download again multiple times. Take note of the download time.

Conclusion

From your testing, you will notice that accessing a website through a CDN endpoint is much faster than accessing the actua web server itself. From your comparison you normally would save 50-75% of the time in loading a site through CDNs.

The common static files are usually offloaded to CDNs so the loading of the actual site is fast and the web and app servers can focus on running the application much better.

On the internet, there are many bad actors which would hit websites randomly. CDN providers with their massive networks also offer the protection you'd need so you don't need to host the website yourself. In our case, we used AWS Cloudfront in hosting the CDNs.