Forum OpenACS Development: Response to Cacing of database queries ...

We could provide a more intuitive user experience by tying cache flushing into the user interface for the cached object. With these controls, I'm not sure we need global parameters like a default refresh time. Maybe your users have requested different functionality than mine - if so, please share :)

Valid points here and in your previous paragraph.

In the Greenpeace project we

had a non-negotiable launch date to meet
inherited hopelessly broken code from a previous vendor that we could only partially fix given the non-negotiable launch date
have hardware spec'd by a third party and with which the site must run for about one year while growing steadily in traffic (by adding additional Greenpeace national sites to the server)
had a fixed budget

Given the above circumstances, when I told them that they had to either accept a very simple caching solution or watch their server melt, they agreed. It had to be something I could implement in an afternoon (though I put in an extra morning after testing of my first hack showed that even the simple approach was a big win). It's an unusual circumstance and by no means do I suggest that a simplistic solution of this sort is really acceptable to all.

You're right that caching portions of pages would be a big win. I've been thinking about ways to cache the output of the ATS "multiple" tag, for instance. This would be even better than caching the underlying "db_multirow" query.

Is it too much work to ask developers to track their own cache dependencies? Well ... it's certainly error prone. Interestingly a couple of days ago Peter Marklund asked Lars Pind if he was caching the front page of pinds.com. Lars said "yes". Peter said "I thought so, I see something doesn't change on the front page when I (post? - Don forgets the exact point)". Lars said "oops, that's a bug" and then fixed it of course.

The point of this anecdote is that Lars is a very good programmer, his site's fairly simple, and yet he managed to slightly botch his personal cache code. We have a bunch of skilled volunteers working on OpenACS 4, we have the beginnings of a formal testing program, but there's no way I'd claim we that at the moment we can exercise the level of Q/A that a mature software company can. And we know how hard it is for software companies to exercise good Q/A. So I worry about introducing mechanisms that are potentially highly error-prone.

In practice if a package has its own cache pool for query results (or html snippets from the template system or both), it should be easy for the developer to remember to zap the cache when new content (a bboard post, etc) is added. Wholesale zapping of package content should still result in enough caching to greatly boost overall performance, because content is added fairly infrequently to any given package even on relatively busy systems.

That's the easy part. Permissions changes are problematical - maybe we define package callbacks for permissions changes on content the package owns? Other than permissions, what other global tables invalidate package content when they change? Any? Permissions is what comes to mind.

Perhaps simply caching multirow (or template multiple tag results) and not caching other queries would be sufficient for the general toolkit. After all, most sites work fine without any caching whatsoever. Perhaps more sophisticated caching needed for very busy, complex sites need not be addressed by the toolkit out-of-the-box. If caching were restricted to such queries in the toolkit proper, I think we could get away with simple flushing of package-specific cache pools whenever the package modifies its content, or whenever permissions on an object owned by the package change.

Would this get us, say, 75% the benefit of a more complex scheme? If so, how many sites would need anything more complex? Hardly any, I imagine.

I don't know, though. The purpose of this thread is to trigger discussion, so let's keep on with it. I appreciate your sharing your experiences ...