|
Home > Archive > Perlbal > October 2006 > Perlbal as an accelerator for dynamic-but-cachable content
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Perlbal as an accelerator for dynamic-but-cachable content
|
|
|
| Hi all,
As it is, Perlbal makes a great "accelerator" for application servers.
By buffering and handling connections, it takes a huge amount of work
off the fat and slow backend servers. It's also amazingly good at
serving static content efficiently.
These are totally useful, and help a lot, but why, oh why, does it not cache?
Much of the content that is generated by application servers these
days is dynamic content, but it is frequently highly cachable.
Caching this stuff is a massive gain on busy sites, because with it,
an application server may only have to generate one request for every
10k requests that arrive.
With Perlbal every hit makes it back to the application servers.
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?
If I wanted to take try implementing some simple in-memory caching,
what would be a good approach with Perlbal?
Thanks all,
Jake
| |
| Brad Fitzpatrick 2006-10-10, 1:12 am |
| You could do it in Perlbal pretty easily, but you'd need some hooks to
snarf the content as it went by, instead of passing it right to the
client. Shouldn't be hard.
On Mon, 9 Oct 2006, Jake wrote:
> Hi all,
>
> As it is, Perlbal makes a great "accelerator" for application servers.
> By buffering and handling connections, it takes a huge amount of work
> off the fat and slow backend servers. It's also amazingly good at
> serving static content efficiently.
>
> These are totally useful, and help a lot, but why, oh why, does it not cache?
>
> Much of the content that is generated by application servers these
> days is dynamic content, but it is frequently highly cachable.
>
> Caching this stuff is a massive gain on busy sites, because with it,
> an application server may only have to generate one request for every
> 10k requests that arrive.
>
> With Perlbal every hit makes it back to the application servers.
>
> 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?
>
> If I wanted to take try implementing some simple in-memory caching,
> what would be a good approach with Perlbal?
>
> Thanks all,
> Jake
>
>
| |
| Mark Smith 2006-10-10, 1:12 am |
| > 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@danga.com
| |
| Ask Bjørn Hansen 2006-10-10, 1:12 am |
|
On Oct 9, 2006, at 18:07, Jake wrote:
> 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?
Many of us have sites with pages that can be mostly, but not entirely
cached. Or sometimes the page can be entirely cached, but you need
to run a bit of logic to figure out which variant of the page is to
be served (etc etc). Doing it in the backend is much easier to
scale than if you start adding too many smarts to perlbal.
- ask
--
http://www.askbjoernhansen.com/
| |
| Chris Hondl 2006-10-10, 1:12 am |
| We've been using memcached directly from our Perlbal instances for caching.
We wrote a plugin to Perlbal that takes inbound URLs, does a tracker lookup
to find a storage node, and then pulls the image from that node. We used an
async memached client library we had written for an earlier project. We
cache both lookups against our Mogile trackers and the images pulled from
our Mogile storage nodes. We run a memcached instance and a Perlbal
instance on each front end machine. We haven't posted this code any
where, but we could publish if anyone is interested.
Chris
On 10/9/06, Ask Bjørn Hansen <ask@develooper.com> wrote:
>
>
> On Oct 9, 2006, at 18:07, Jake wrote:
>
>
> Many of us have sites with pages that can be mostly, but not entirely
> cached. Or sometimes the page can be entirely cached, but you need
> to run a bit of logic to figure out which variant of the page is to
> be served (etc etc). Doing it in the backend is much easier to
> scale than if you start adding too many smarts to perlbal.
>
>
> - ask
>
> --
> http://www.askbjoernhansen.com/
>
>
>
--
http://avatars.imvu.com/chris
| |
| komtanoo.pinpimai@livetext.com 2006-10-10, 1:12 am |
| I'm eager to see, I was naively writting a plugin to lookup MogileFS key
without passing to modperl, but it didn't work, because perlbal needs
something asynchronous. Since then, I have been wondering how to do it
correctly.
-kem
On Mon, October 9, 2006 10:26 pm, Chris Hondl wrote:
> We've been using memcached directly from our Perlbal instances for
> caching. We wrote a plugin to Perlbal that takes inbound URLs, does a
> tracker lookup to find a storage node, and then pulls the image from th=
at
> node. We used an async memached client library we had written for an
> earlier project. We cache both lookups against our Mogile trackers and
> the images pulled from our Mogile storage nodes. We run a memcached
> instance and a Perlbal instance on each front end machine. We haven'=
t
> posted this code any where, but we could publish if anyone is intereste=
d.
>
> Chris
>
>
> On 10/9/06, Ask Bj=F8rn Hansen <ask@develooper.com> wrote:
>
o[vbcol=seagreen]
an[vbcol=seagreen]
>
>
> --
> http://avatars.imvu.com/chris
>
>
| |
| Brad Fitzpatrick 2006-10-10, 7:12 am |
| Use Gearman. Check out gearmand and Gearman::Client::Async, both on CPAN.
You can use the Gearman::Client::Async from Perlbal plugins really easily.
On Mon, 9 Oct 2006 komtanoo.pinpimai@livetext.com wrote:
> I'm eager to see, I was naively writting a plugin to lookup MogileFS key
> without passing to modperl, but it didn't work, because perlbal needs
> something asynchronous. Since then, I have been wondering how to do it
> correctly.
>
> -kem
>
> On Mon, October 9, 2006 10:26 pm, Chris Hondl wrote:
at[vbcol=seagreen]
t[vbcol=seagreen]
d.[vbcol=seagreen]
o[vbcol=seagreen]
an[vbcol=seagreen]
>
>
|
|
|
|
|