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
- Consider creating a number of sub-domains for auxiliary content, for example static1.acme.com, static2.acme.com etc
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.
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