Perlbal as an accelerator for dynamic-but-cachable content

[Mark Smith]

> What is LiveJournal (or others) doing to serve up these
> dynamic-but-cachable requests efficiently? Are they just optimizing
> dynamic generation (memcached, etc) so it doesn't hurt so bad, and
> buying additional servers?

The only things on LJ that are really hit "that much" would be userpics or
static resources.

The latter are served locally by Perlbal and never hit the backends.

The former are cached using the reproxy cache.  Perlbal doesn't have to hit
the backends then, it can go straight to the mogstoreds.  Even without this
enabled, though, LJ has enough capacity to keep up just fine.

> If I wanted to take try implementing some simple in-memory caching,
> what would be a good approach with Perlbal?

It's something we've talked about.  I don't remember what Brad's opinion is
on it.  It's not really relevant to LiveJournal because all of our pages
are entirely dynamic - there's very little on the site that doesn't change
based on who's viewing it.

It's definitely something you could consider doing through a plugin.  Setup
a response handler that just copies to memory as it's sending to the user.
The system would need to be an LRU cache with the following tunables:

* max resource size (don't cache things bigger than this)
* max cache size (throw out items when we hit this size)

But yeah, the hard part is going to be coming up with a way of figuring out
what you can cache.  That doesn't seem very likely to be something that can
be put into the core very well.

--
Mark Smith
junior at danga.com