The title of this post says it all, really. But the long story follows… (this made TheServerSide. Unfortunately I can’t login there – I think that’s our work firewall problem – so I’ll update here to give a few more details)..
So at work we use a Java based CMS. It turns out that this particular CMS does tens of database queries for every pageload. Surprisingly, this doesn’t scale well….
We’ve added our own caching layer(s) which have helped the speed some, but it’s still not reliable enough to be satisfactory.
In the past I’ve fixed a problem like this by using curl to make a static copy of the site and some mod_rewrite magic to redirect visitors. In this case that’s unlikely to work, because there is just enough dynamic content to make it more trouble that it is worth.
The obvious solution is a rewrite, but that isn’t going to happen, and I don’t want to be doing any more patching of the *&$!#@ CMS.
The only thing I can think of is to use Pound as a load balancer, with a second copy of the CMS taking over the content generation when the first one crashes and restarts. I think that will work, but it is kind of a band-aid solution and comes with a whole set of its own problems. For example, it doesn’t look like running two copies of the CMS off the same database will work, so we’ll need to replicate the database. Then we’ll need to make sure the content updates go to the correct CMS/database combination.. etc.. etc.
All in all I think we are up the proverbial creek. But if anyone has any ideas.. I’m all ears.
Update: I’m reluctant to name the CMS, but it isn’t Vignette. If have a good reason to know I’ll try to respond to emails. That database is Postgres 7.4. Load on the database isn’t a huge problem, but it looks to me that the number of round trips to build a page is (when I say “tens of queries” – it’s a lot more than 10 – more like 50).
We’ve implemented some custom caching using a EhCache filter and OSCache JSP fragment caching.
The specific problem isn’t performance – it’s stability. After a some hours running the site just stops responding. We’re currently trying to figure out the exact cause of that via stack dumps, but with hundreds of threads it is a difficult process.
A front end cache won’t work, because the CMS uses the ‘Vary’ header, which makes pages uncachable. (Actually – I’m considering writing a filter to strip out that header so I can try using Squid).
The vendor doesn’t respond to support request. Yes, we have a support contract, and yes, that is pretty bad.