Skip to main content

AWS S3 versus CloudFront Performance

Yesterday I took Amazon CloudFront for a spin. Creating the CloudFront distribution was pretty simple - the wizard process flowed nicely. I found myself relying on the help text in places, but the most surprising thing was how long it took for the distribution to become enabled. I didn't time it exactly, but I probably spent 45 minutes waiting for my new CloudFront distribution to change from "In Progress" to "Enabled" status.
The performance is a bit confusing. Compared to the S3 bucket, I didn't see any improvement in performance in a few tries - in fact, the CloudFront CDN performance was worse than the S3 bucket on its own for my 217 KB image file. I decided to take a larger sample, loading the same image 30 times in Chrome and noting the timing data from the "network" tab in the developer tools. I'm located in Brooklyn, have CloudFront configured for the US/Europe with download mode configured. My S3 bucket is in the US Standard zone, which is probably on the east coast. Here is what I found:
CloudFront    S3      
Mean 343 ms 305 ms
Std Dev    230 ms 170 ms
The first observation is that there's a lot of variance in the performance of my ISP. The second is that the mean response times are pretty similar, and the relative frequencies in my samples are nearly identical (sorry no graphic - need to find a good tool for generating graphs for the blog). So I can't see any meaningful difference between S3 and CloudFront for my ISP in Brooklyn. However, I tested only with a single modest image, so there might be a more notable difference for other file sizes.
Some interesting statistics about performance from other regions of the country suggest the locality of the user is an important factor. I would expect that users who are more rural or are located further from the eastern United States would notice better performance over CloudFront than using S3 buckets in the US Standard configuration. For those of us located in close network proximity to our S3 buckets, the level of optimization in S3 seemingly matches that of the CDN.
I did this test to decide where I want to serve static images from for my demo site. For now I think I'm going to leave the CloudFront CDN enabled. My traffic volume is low enough that the cost isn't a big factor and the performance is probably better this way for some potential visitors.
Labels:
Location: Bay Ridge, Brooklyn, NY, USA

Comments

Post a Comment

Popular posts from this blog

ReactJS, NPM and Maven

I'm just starting to get into working with ReactJS, Facebook's open source rendering framework. My project uses SpringBoot for annotation-driven dependency injection and MVC. I thought it would be great if I could use a bit of ReactJS to enhance the application. If you're looking for a basic conceptual intro, I recommend ReactJS for Stupid People and of course the official documentation  is quite good. In full disclosure, I still have no idea how to do "flux" yet. As an experienced Java backend developer, I'm pretty decent at hacking Maven builds - which is precisely what this blog post is going to be about. First, a word about how React likes to be built. Like many front-end tools, there is a toolkit for the node package manager (NPM). From the command prompt, one might run npm install -g react-tools  which installs the jsx command. The  jsx  command provides the ability to transform JSX syntax into ordinary JavaScript, which is precisely what I want...
21 comments
Read more

Cryptic Facebook Message

Facebook OAuth2 is a feature I frequently integrate, but sometimes its error messages can be downright opaque. In particular I keep on forgetting to associate my Facebook account on applications where Sandbox Mode is enabled. The error message in this case is the following: Sorry, this feature isn't available right now: An error occurred while processing this request. Please try again later. This message is super cryptic, since what I usually need to do is to register my account as a tester or admin on the Facebook application page. If you get this error message here are the steps to fix it: As an application administrator, go to the OAuth2 configuration page for the application in Facebook. Add the Facebook account as an admin or tester on the "edit roles" screen. This will send an application request to that account. As the added account, accept the application request to become an admin or tester. At this point the Facebook login should work for the accou...
1 comment
Read more

Generating a Self-Signed SSL Certificate

I recently switched some web services to use SSL, and I was surprised that I couldn't find a good non-interactive script to generate the files needed for Jetty and other Java containers. After working my way through writing the script, I have decided to share my approach. This script generates a SSL subdirectory of whatever folder it lives in, and to that directory it adds a password file, certificate and a Java-friendly PKCS12 version of the certificate. And then I have my Maven build process copy the generated files into the base of my classes directory. The embedded Jetty instance needed an input stream of the PKCS12 file and the contents of the password file to create a SSL connector. Reading from the classpath can be a bit tricky - I should post about that later. From past experience, I think Nginx also requires the certificate file when configuring SSL.
Post a Comment
Read more