|Post date: 2010-10-06 21:11|
First time implementers of caching often stand confused to what can be cached. I have had a client that was absolutely certain that all caching was bad - that only prevented us from showing the latest information. Obviously they had bad experiences with wrong set caching in the past.
Ideally you would design your web applications with caching in mind from the start but it is not uncommon that you have a situation with a lot of existing web applications and you have to start identifying static content.
So, deciding on what to cache and not to cache. I would like to break it down into three categories:
- Definitely static content. Will not change at least not for a long time. This is images, CSS and the like.
- Definitely NOT static content. Views, certain forms and content protected by user access.
- Semi static content. This is tricky. Let me explain.
Semi static content is content that might change a couple of times a day. Say you have a company intranet start page.
You would like the page to be very fast as it loads hundreds or thousands times per day and it has probably matured over time to contain WebQueryOpens, 10-50 DbLookups, Repeatcontrols or whatever web designers have put in there.
Setting a cache time of 1-10 minutes will save the server a lot of repeat hits and your users will still get the latest version the first time they hit the page - they will just miss out for 10 minutes if there is a change after that.
For static content setting up web rules to set expires headers on images is the only way. For HTML and CSS files you have the option to set the expires headers with the @SetHTTPHeader.
If you are using Domino Accelerator Pack you will also have server side caching. DAP will look at content being sent to the users and cache content in memory depending on their cache settings.
If we take the example of the frequently used company home page. If we can cache it in memory for just one minute on the server Domino will only have to recalculate the page once every minute and you would only have a one minute delay of updates.
All requests would be served compressed directly from memory meaning 0 ms render time.