About WCM rendering performances

We launched our intranet early 2007 in production....What a big effort ! It is always what I say after each portal project deployment. As for today, my experience is that even a "small" portal project requires at least 6 month before going live in production. But planning is not the subject of this post.

When I joined the project, the team was facing a lot of performances issues. The first reason is that people didn't really take care about response time constraint when doing custom developments...It is often the same problem: development team must deliver new features quickly and people are not always ready to invest time (and money) to design a robust solution, with a good caching strategy.
However, thinking about how to design and implement a cache should be studied carefully for every project which should run under heavy load.
So before going live, we spent a lot of development effort on each components: theme, WCM Portlet, and back-end Portlet. The biggest issue was how to optimize the WCM Rendering Portlet response time (because our site is mostly composed by WCM Portlet for the moment).
We, in my company have implemented a custom WCM/WPS java framework, mainly to implement the multi-language capability in WCM. Because of this custom layer, most of the standard WCM caches was not appropriate in our context. Indeed, WCM does not support multi-language, so neither does the WCM cache....
We now have created several type of caches, for several kind of WCM Objects, all based on the WAS dynacache. Dynacache is a good way to cache object, and it is really simple to use.
One of the most powerfull cache we have developed is working as follows: through a custom JSP component, we are able to retrieve the full HTML output of the Portlet and to set it in cache. Next rendering phase are really optimized because there no request to the WCM repository at all (only a lookup in the dynacache).
We also tried to directly cache the WCM content object into our own cache...but this is simply something to avoid because WCM object are associated with the workspace which was initially used to retrieve them from database. So except if you only use public WCM content (visible by every user), which could be the case for internet web site, this approach should not be selected.
For the moment, most of our caches have been enabled for the public area of our site (for anonymous user). In this case, the caching strategy is simple because we do not have to worry about content security (and cache key are really simple). If you implement your own cache, you should carefully think about security access for object which are stored into cache.
We now have really good response time for our public pages. But now, more and more people are connected to the intranet, and they clearly see that response time are not so good after authentication (the HTML output caching is not enabled)...It is hard to understand from the end-user point of view.
So our next challenge is to think about how to cache WCM content, for the authenticated user. One of the biggest problem in this case is how to share cache entries for people which share the same profile. In our context, it is hard to mutualize cache entries, because peoples belongs to distinct UserGroups, and it is difficult to identify generic profiles.
I think other option will be to use Ajax. As we always use WCM JSP component to perform the WCM Portlet rendering, that is technically possible. However, I'm wondering if using Ajax on every WCM Porlet will not generate some side-effect (especially if several Ajax servlet tries to access to the WCM repository at the same time)....I will try to give some update about this problem in a next post.