Loading ...

Would you like to discuss your environment with a knowledgable engineer?

Preferred communication *

Thank you. We will be in touch with you shortly

Architecture for effective caching

The following recommendations will make scaling your site with aiScaler much easier.
  • Move personalization/customization logic to client-side (things like “Welcome back Mr. Smith”). For more information, please download our Personalization PDF.
  • 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, aiScaler 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 aiScaler 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. aiScaler 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 aiScaler, 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


US 1 (408) 744-6078   EU +44 20 7993 4587