aiCache Wiki‎ > ‎

Architecture for effective caching

The following recommendations will make scaling your site with aiCache mush easier.

Move personalization/customization logic to client-side (things like "Welcome back Mr. Smith")

Use a separate sub-domain for secure (HTTPS) version of the site. example secure.yoursite.com

Create a caching-friendly URL naming convention. For example, group all images under /static/images/*  
Javascript under /static/js etc.

Consider creating a number of sub-domains for auxiliary content, for example static1.acme.com, static2.acme.com etc

Allow for prolonged caching of javascript (.js), content style sheets (.css), images (.png, .jpg, .gif etc) and other auxiliary content, that is not changed frequently. Few days for auxiliary  images and few hours for CSS and JS files are  a good estimate here. Remember, aiCache serves cacheable content in  a way that allows it to be properly cached by visitor’s browsers  and this will lead to even more benefits, 
eliminating the need for conditional requests  (If-Modified-Since and If-Match)  and 304 responses altogether.

Sometimes, caching even for few seconds makes a tremendous difference. Imagine a URL that receives 100 requests a second. Without  aiCache each and every one of these will head straight to the origin servers and most likely  past that as well  – right to app servers and DB servers. If you enable caching for just 5 seconds, then origin server will only see 1 request every 5 second. That is 500-time reduction 
of traffic to your origin servers and the rest of your infrastructure. Could be a difference between a site that cannot stay up even with dozens of origin servers (and matching number of App and/or DB servers)and a site whose footprint can now be reduced to say just 2-3 origin servers ! Meaningful results can be obtained even with 1-2 second TTLs for the busier URLs.

Normally it will be  responses to GET requests that we configure for caching. However, some of sites use POST requests for their search forms and such.  aiCache allows for caching of POST requests, although you must be careful with these, to prevent personal data from becoming shared by mistake.

Consider employing some form of versioning for auxiliary content if you want to have full control of your web pages. For example, if a web page references a Javascript file called script.js  and you need to modify that file, you might not be able to guarantee that all of  your site visitors will see the new file content right away  - as an older, cached version  script.js might still out there in corporate and ISP 
HTTP proxies and in local browser caches. A very simple fix to change the SRC attribute of the  Javascript file to  scriptV2.js  and rename the file itself to match this name. Now the change is instantaneous and assured right after you publish the HTML page that references this JS file.

It is important to mention that with aiCache, you do not have to modify anything on your origin  web servers, App or DB server  nor do you have to ask  your Dev team to write any code to handle freshness control  that crowd always has plenty of projects to work on as is. This allows you to control freshness of the content with great ease and minimum overhead, all configured, on-the-fly, with no user impact, at a single source

Sign in  |  Recent Site Activity  |  Terms  |  Report Abuse  |  Print page  |  Powered by Google Sites