There are lots of way to optimize your site to make it go faster, and reduce your server load. This usually involves lots of tweaking your code and database, and can be quite a challenge when you want to to speed up a dynamic site, such as an ecommerce site.
aiCache offers you a shortcut for this, and promises it can speed up your site within 10 minutes with a speed improvement of up to 10x. Let’s see if that’s true.
What is aiCache?
As the name suggests, aiCache is a caching solution for your website. You put it in front of your own servers, and route your traffic over your aiCache server.
Built with the cloud in mind, you can deploy it as an Amazon EC2 AMI instance, which allows you to scale up when traffic rises.
It allows you to cache a dynamic site without changing your code.
It claims that on one (!) well configured server you can serve up to 160M reg/hr. aiCache also optimizes your site for mobile visitors, and gives you the ability to set it up as an DDoS firewall.
How does it work?
aiCache acts as a proxy, it will load the site as any client and then all the content specified in your config will be loaded into the instance’s RAM. This is where a major page load improvement comes from, and this relieves your origin server.
Each request received to your site is then loaded from this cache, which is updated when you change your content (based on the TTL of your content). It will only cache the content from your site itself. Externally loaded resources (tracking scripts for example) will still be loaded from it’s origin server.
You can use aiCache in a load balanced configuration, for redundancy. You can also use aiCache instances for your own global distribution network, using their partner Dyn. You simply deploy an instance in each region you desire, and set up traffic distribution rules. This way you can basically build your own smart CDN, not only for your static files, but for your dynamic pages as well.
Speeding up SitePoint.com
Now let’s find out what kind of speed improvement you can expect. aiCache provides a nice tool for this. Using SitePoint.com as an example, these are the current results:
aiCache servers hosted in: US East – N. Virginia and US West – N. California. Original is hosted in US-East.
| Test location | Original website | aiCache US East | % | aiCache US West | % |
| San Francisco | 4.861 sec | 3.834 sec | – 21% | 3.782 sec | – 22% |
| Singapore | 8.85 sec | 6.44 sec | – 27% | 6.426 sec | – 27% |
| Dublin | 5.958 sec | 4.274 sec | – 28% | 4.546 sec | – 24% |
| Washington DC | 4.589 sec | 4.078 sec | – 11% | 3.422 sec | – 25% |
Note: aiCache uses Amazon AWS for this test. The load times are measured by Neustar.
As you can see, a 25% load time improvement should be easily achieved, even on a standard setup of aiCache. You can tweak it even further to improve these results. And besides reducing loading times, it also decreases your server load heavily so you can lower your hosting bill.
As this looks promising, it’s time to set up an aiCache for myself and see if it’s really that easy.
Setting Up the aiCache EC2 Instance
Before you can do anything, you need a working Amazon AWS account. You can start aiCache up from their own website, or do a search for it on the AWS Marketplace. You have to subscribe first, after which you will deploy an EC2 instance from the EC2 Dashboard.
What you exactly need to fill in is described in their Wiki, but you basically have to make a configuration file to specify which site you are powering up. You can store this in Amazon’s S3 for convenience. When this is done you’ll head to the EC2 section of AWS.
From the navigation on the left you can fire up the AMI screen, and do a search in the public AMIs for aiCache.
After selecting the right AMI, you can launch your instance.
I used the small instance for my example. After selecting it, you have to go through the EC2 routine to configure your instance. This is also the part where you have to fill in the the link to the config file you made in S3.
Then you launch, and wait for the instance to come alive. You can check if it’s working by filling in your public DNS in your browser. If the supposed site is loading, you’re okay.
And that’s it. It really takes just a few minutes to set it up. Waiting for your instance to come alive after launching it takes longer than configuring it. Once you are satisfied you only have to change your A record in your DNS settings, and you’re set.
Test results
After deploying my own instance, I did some tests on the load time again:
| Test location | Original website | aiCache US East | % | aiCache US West | % |
| San Francisco | 4.92 sec | 4.71 sec | – 4% | 4.72 sec | – 4% |
| Singapore | 11.7 sec | 7.65 sec | – 35% | 8.08 sec | – 31% |
| Dublin | 6.88 sec | 8.03 sec | + 17% | 7.68 sec | + 12% |
| Washington DC | 5.52 sec | 4.06 sec | – 26% | 3.49 sec | – 37% |
Note: All the tests are done multiple times to exclude glitches
There are some interesting findings:
- The load times for San Francisco are the same for both the optimized and non-optimized site. This was consistent on every load.
- Singapore would require an instance hosted locally to really benefit: even though the reduction is vast, load times are still too high.
- Not much to win for Dublin, this would require a local instance as well.
- The results for Washington DC are spectacular. And the aiCache sites were performing consistently, while the original site was bouncing up and down in load time.
- The original testing and my tests were performed at different dates and times.
Even though Sitepoint.com is well cached, it’s still a heavy site. It also loads a lot of external requests (mostly advertising) which aiCache can’t cache. But there is enough room to improve, at least for the west coast.
And these are just raw data: because of the caching, most of the visual loading of the site is done in just tens of milliseconds. This means that the visitors would experience your site as extremely fast, since most of it is shown before it’s fully loaded. And then there’s also the benefit of reduced server loads, even with just 4% load time reduction (like in San Francisco). This means cutting a few front-end servers, thus lowering your bill.
Now look at some other examples, to see where aiCache can benefit the most.
WebtoolsReview.com: One of my own sites, currently being developed. Uses only the basic Twenty Eleven theme from WordPress.org, no external resource, only sample content.
| Test location | Original website | aiCache US East | % | aiCache US West | % |
| San Francisco | 2.049 sec | 0.806 sec | – 61% | 0.968 sec | – 53% |
| Singapore | 5.111 sec | 2.226 sec | – 56% | 2.285 sec | – 55% |
| Dublin | 1.94 sec | 0.854 sec | – 56% | 1.239 sec | – 36% |
| Washington DC | 1.368 sec | 0.754 sec | – 45% | 0.779 sec | – 43% |
As you can see, the original loading times are already very slow. Caching still shaves off around 50% of loading time.
Let’s see what AiCache can do for some of the largest (and best optimized) sites in around.
| Test location | Original website | Original website | aiCache US West | % |
| San Francisco | Google.com | 1.52 sec | 0.968 sec | – 36% |
| Washington DC | Google.com | 1.475 sec | 0.798 sec | – 46% |
| San Francisco | Youtube.com | 2.565 sec | 2.349 sec | – 8% |
| Washington DC | Youtube.com | 2.863 sec | 2.072 sec | – 28% |
| San Francisco | Yahoo.com | 3.349 sec | 1.264 sec | – 62% |
| Washington DC | Yahoo.com | 3.414 sec | 0.896 sec | – 74% |
For this test I only used the US server results.
As you can see, even Google.com, a very light site, can benefit from caching. Youtube.com, on the other hand, won’t benefit as much. As you can see in the waterfall below, their homepage loads a lot of images and small .js files, which are already served at the speed of light.
Yahoo.com can truly benefit from AiCache. It is a resource heavy site, which just loads faster when served up from memory, no matter how good your CDN is.
Youtube waterfall.
Pricing
To be honest, aiCache comes at a cost.
Amazon currently is deploying a new developer payment model, but the “cheapest” option is by ordering it using the link on the aiCache site (order aiCache). They want to keep the pricing simple: An aiCache instance is twice the cost of a base instance. This comes down to $0.13 per hour for a small instance where you would normally pay $0.065 per hour for a base instance. There is also a $15 monthly fee for support. Running one instance costs you $108.60 per month.
This seems a lot, but in order to almost break-even this means cancelling two small (non-aiCache) instances, or one standard (not considering the monthly support fee). That is assuming you run three or more instances, since you always need your origin server.
Conclusion
aiCache looks like a great product, if you need it. It might not always give you a real speed improvement, but it does relieve the load on your server as an added benefit.
It’s a pricey solution when you’re only just running one server, but it may be a cost saver when you’ve got multiple instances working for you. And remember, in this review I only touched their caching feature, but there’s also mobile optimization and DDoS protection.
My own experiences confirm that they have a fantastic support team who helped me a lot with my research questions.
If you want to know if you can speed up your own site too, here’s the tool to do it: http://aicache.com/deploy.
Jacco BlankenspoorJacco Blankenspoor is a website developer from the Netherlands, and is currently just building lots of different websites. When he is not working on HIPAAHQ.com you might catch him grinding coffee.
