Making cache

Slow websites, gotta hate them! I mean, even on my iPhone  I get impatient when the news slowly trickles in. And there it is merely a case of not having the right connection. Luckily, on my computer I have several megabits working together trying to get the information from there to here in the blink of an eye. If the information does not feel like coming over, or if it comes in the blink of a cup of coffee, I'm out. Google will name me three others that have just about the same information for me.

All of this is understandable from the viewpoint of the web consumer. It places some stress on the information producers, though.

Let's face it, constructing a page is a lot of work. Data has to be retrieved from several places, business rules have to be applied, access has to be checked, elements have to be juggled around and glued to the right spot. And that's just for the HTML of the page, not even touching on the subject of script files, stylesheet files and extra data files. Rendering a single page will cost the server processing power.

In contrast, serving a file from disk (or better yet: memory) is considered cheap. Behold, the birth of the idea for server side caching!

What if we generate a page, store it on disk and then serve it from disk? That way, the page can be sent out from disk many times. As long as the content on the page doesn't change, it will be just fine.

The architects of GX WebManager have thought long and hard on this concept. The result is a smart caching mechanism that only renders pages when necessary. And even better: the pages are cached without personalization! This means that both your page ("Hi Reader!") and my page ("Hi Patrick!") come from the same cached disk file. The personalized information is added after caching. I will devote another blog entry on the exact workings of personalization in GX WebManager. Suffice to say that when I explain the concept, nine out of ten people say that it is "quite smart". One out of ten exclaim "It's brilliant!" ;-).

 WCB developers need to keep WebManager's caching mechanism in mind while developing. As can be seen in the image, your WCB lives behind the Caching module. This means you cannot presume to be rendered by a concrete request by a visitor. So you cannot read a session value like a cookie from withing your JSP code, not meaningful at least. For the first visitor it will probably work. But the second visitor gets her information straight from disk, not from your JSP. Instead, you should create a personalization expression to do something meaningful with the cookie value. Or do some server side include trickery. But more on that in a later blog posting. In the mean time, you can read up on caching in the documentation. ;-)

So developers, beware! Keep the picture above in mind when designing your WCB's.
As Snoop Dogg would say: "Respect tha Cache"!

Till next time,

Patrick