Amazon Web Services Simple Storage Service (S3) accessed directly with 500 non-cached requests.
  These test shows the difference in performance, when using objects from Amazon Web Services, Simple Storage Service (S3) to build a dynamic website, and using the same service cached with instances of aiCache Dynamic Caching running as an instance between S3 and the web tier. The comparison assumes that users of a site, are repeatedly using the same files within the TTL (Time to Live), specified for the cache. SAMPLE CONFIGURATION  Complete details of the test environment and results are shown below.
 OUR TEST ENVIRONMENT Our testing setup used an Httpd (web Server), running on an AWS small linux Instance. The test page contained 500 embedded image files. The objective was to have a broad enough range of files, that would simulate random requests from an active web page. Every object had to be downloaded by the client Browser and can be cached by aiCache. The original site http://bucket.name.s3-website-us-east-1.amazonaws.com (we tested in us-east-1 region). aiCache had a standard configuration pointing to hostname bucket.name.s3-website-us-east-1.amazonaws.com and had enabled caching for all static objects like .js, .css, .jpg, .gif, .png, .swf, .html. All objects matched caching rules. The TTL's for caching (the time until next update of the cache) was 1 day for html, and 7 days for other content, this was arbitrary and could range form 1 second to infinite time. We accessed the site through aiCache the first time, so all objects where held in cache. This would be the same as the first user to access the page would see the cache. From this point forward, all content is delivered by aiCache memory. We made several tests to show the difference in accessing the site directly from S3 and from the cached version. We also tested from an instance started in the same region (us-east-1) with apache bench. The apache bench stats are more specific but take a little understanding. To simplify we used the Browsermob site to do a raw speed test from several global locations. These results are listed here. This demonstration is not intended to be comprehensive for all sites. It is quite simple to re-create this test environment, using an existing site to provide a real life proof of concept. The important piece of this test from our perspective is: Average time to receive an S3 files that was cached was reduced by 3x to 10x. Files that where not cached, but still accessed via aiCache where on average 5% faster (better session management). We did not need to know the specific files that where to be cached in advance, only the regular expressions. Notes: This environment is limited by the memory of the aiCache instance and would not work well for very large files or streaming. Network latency was largely ignored in this configuration. Geographic distribution was not used. Caching TTL was arbitrary and can range from 1 second to unlimited by regular expression. |
|
aiCache Wiki >
AWS S3 DYNAMIC CACHING |