Building a user level caching with dynamic content
Posted on 2008-09-12 13:36:13 EEST.
Caching can be the most essential part of website developement since it can greatly affect to the site responsiviness and how well does your site cope with sudden increase of hits.
Things are quite simple when you have just static content or dynamic content where all data is common to all users. But what if some part of your site requires per user tailored content. Things start to get immediately a lot more interesting.
Lets take a normal page. There are for example following parts:
1. Header and the very beginnings of the page
2. Some personalized content. User's latest messages etc.
3. Latest news
4. Latest comments
5. The ending of the page
As a caching point of view this page should now be divided to three chunks.
1. Part #1 (public)
2. Part #2 (private)
3. Part #3-#5 (public)
So basically it means that when we got a request, caching engine should request those three chunks. There should be some logic around that kicks in at the second part. Perhaps if that code is not cached, then that code that generates it is fired.
The part two can as well be totally uncached if required so. But in the end the challenge comes how to invalidate those parts and how to keep cache as intelligent as possible. For example that private part can be same per each request. That's why for example cache keys cannot be totally request based.
Interesting challenge. Let's see how this all be done with MidCOM 3.
Things are quite simple when you have just static content or dynamic content where all data is common to all users. But what if some part of your site requires per user tailored content. Things start to get immediately a lot more interesting.
Lets take a normal page. There are for example following parts:
1. Header and the very beginnings of the page
2. Some personalized content. User's latest messages etc.
3. Latest news
4. Latest comments
5. The ending of the page
As a caching point of view this page should now be divided to three chunks.
1. Part #1 (public)
2. Part #2 (private)
3. Part #3-#5 (public)
So basically it means that when we got a request, caching engine should request those three chunks. There should be some logic around that kicks in at the second part. Perhaps if that code is not cached, then that code that generates it is fired.
The part two can as well be totally uncached if required so. But in the end the challenge comes how to invalidate those parts and how to keep cache as intelligent as possible. For example that private part can be same per each request. That's why for example cache keys cannot be totally request based.
Interesting challenge. Let's see how this all be done with MidCOM 3.