At least, we still use a/the version table to cache versions of nodes, but we also have other caches for long-running queries or queries that only need to change their results rarely (Best Nodes, Chatterbox contents rendered as HTML, ...). For these, it might make sense to store/retrieve them from a cache separate to the database.

I'm a tiny bit reluctant to introduce another separate component to the site, and I have no experience with how the memcached clients behave if no server is available. But as I found that memcached is available for Win32 and has a pure Perl implementation, I'll look into using it, as it could shift some load away from MySQL.

and I have no experience with how the memcached clients behave if no server is available

no problem. if there is no memcached node available, then you use the database. the frontend module will just return undef for the lookup.

Why hesitate? I've been always wondering why the biggest international perl forum (I know) is such a slow website. I thought, there must be a lot of experienced web developers hanging around. Introducing memcached sure is another component, but it's a cache - if there is nothing in the cache, it returns undef and you create what you need from the database. where's the problem?

Ah, but I wonder about how long the client libraries will take to return undef as they timeout if there is no server available, and how they behave if the server gets stuck somehow, accepting connections but not returning results.