Use cache technologies to improve performance of your site.

As the number of users grow, is it necessary to increase the number of servers? Well. The answer to the question really depends. Some might say to buy more hardware to support increasing visits. Some might say before buying more hardware, tune up your software by optimizing the code and squeeze any power out of the box. But in this post, I’m not going to discuss software tune ups.

I’m going to talk about cache technologies.

cache layer
I’d like to start with the concept of proxy layer. What proxy layer provides is a memory storage between frontend(FE) layer and API layer. So that the actual requests made from users do not overload API server; thus, the site performs much better. Proxy server would store returned XML data from API and when the same API request was made from FE, proxy would return the same data stored in the memory to FE removing extra calls to API. Frontend layer is a typical HTTP server while API layer is a data layer. Usually this technique is used in multi tier architecture. This is usual 3 tier architecture.

DB -> API -> FE

When we introduce proxy layer to it, 3 tier architecture becomes this:

DB -> API -> Proxy -> FE

As you can see, the major advantages of Proxy layer are:

1. It is very fast since it accesses memory instead of hard disc
2. It reduces overhead to one layer dramatically
3. It delivers content really quickly
4. It improves response time(better roundtrip numbers)
5. It provides better usability to users as content is delivered a lot faster
6. It can hold old data for specified time in case database blows

It just has all good things.

Commonly used cache technology for the cache layer is squid cache. If your organization’s web site is getting popular and needs performance tune up, it may be a good idea to invest some time and money to implement cache layer.

As I covered cache layer, let’s move to view level cache.

View Level Cache
View Level Cache is a cache technique to store your HTML markup output into memory or harddisc. This could be a whole markup for the page, markup for a partial page, or markup for several parts of the page. As the term implies the view level cache occurs on the frontend layer. Also there is another term, Module Level Cache referring to View Level Cache. For example, in my blog there are several sections in the page. Those are links, archives, and so on. Each section is a module and the final markup of those modules can be cached for 5 mins to how many minutes you like.

What’s so good about View Level Cache(Module Level Cache)
As I explained in the previous paragraph, it stores the final markup of a module. Which means you can reduce cpu load, which would have used to generate that module for the time you specified. That means also it does not have to make several requests to database like MySQL. So when your site got hit by dig users or reditt users, View Level Cache would’ve helped to ease heavy traffic much.

View Level Cache technologies
If you are using php, the common technology for the view level cache is APC. The usage of APC is relatively easy. In php, another technique you can use is a file cache. And heavy traffic’ed sites also use memcached, which is a distributed memory object caching system. I am not going to show how to use each technology in this post as each topic deserves its own post.

Do not cache all by accident
When you apply cache layer to your Frontend, be warned that caching all content is bad usually, specially if your site is dynamic. You do not want to cache user A’s name and display it when user B, C, and D visits your site. Also if one of your pages needs user specific data in a form tag with hidden input field and somewhat you caches it, the next visitor to your site will use the same data from the previous visitor, which is bad. See where I am going with this? So it will be nice if you can communicate with visual designer so that she can visually distinguish what can be cached and what not.

Results out of cache
The site that has implemented cache technique well could support 200 to 300 hits per second. That translates to 12000 to 18000 hits per second. I know this from my experience. You do not need a lot of servers to support 200 hits/sec site. All you need is one FE box if your site has 200 hits/sec.