Re: [mongrel2] LRU cache looking good
- From:
- Alex Gartrell
- Date:
- 2010-07-21 @ 00:33
On Tue, Jul 20, 2010 at 3:06 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> Alex,
>
> The LRU cache is looking good, I just deployed it to mongrel2.org and it
> does give a nice little perf boost in my testing. Code's nice and
> simple too. Here's a few things I'm thinking for next steps with it:
>
> 1. We want a cache on each Dir struct rather than globally. You'll need
> to refactor some Dir_ functions for that to work.
>
Yeah, that makes a lot of sense. Plus cache initialization is pretty ugly
now anyway.
> 2. Once we put the cache on the Dir, we can give a config parameter for
> the database so they can tune it.
>
Cache size and cache time to live? Sounds helpful to me. I think we need
more reasonable defaults (32 was a good number for testing, and not a lot of
thought went into it otherwise).
> 3. I think we should experiment with keeping the contents we read in the
> cache as well as another element on the FileRecord. Not sure the
> implications of this though, but I think it's more reliable for this
> kind of cache.
>
I think this is going to be a win for frequently accessed small objects. We
probably want a maximum size. It might also make sense to have a minimum
hit count to fill it. I'm guessing that sendfile is going to dominate us
for single sends or for huge (too big for memory) sized files, but the
context switch and memcpy from userland is almost certainly faster than
going to disk. I'll roll a couple one-off programs to do a dumb comparison
away from all of the other stuff.
> 4. If we don't do #3 then we have to figure out what happens if the
> contents change in size after read. Maybe use that to do eviction on
> the fly?
>
We might want to wait until time is up to do a stat on the full_path. If
that stat returns the same size and a_time, we can reset the timer (but not
the "freshness" for eviction's purposes). Otherwise we can axe it or reload
it.
>
> Otherwise, rocking. I'll let you know how the main server holds up.
>
>
> --
> Zed A. Shaw
> http://zedshaw.com/
>