Re: assert(e->mem_status == NOT_IN_MEMORY) versus TCP_MEM_HIT.

On Sun, 27 Sep 2009 21:16:29 +0200, Henrik Nordstrom
<henrik_at_henriknordstrom.net> wrote:
> sön 2009-09-27 klockan 12:55 +1300 skrev Amos Jeffries:
>
>> Ah, okay gotcha.
>> So...
>> (c) for people needing a quick patch.
>> (b) to be committed (to meet 3.2 performance goals, saving uselsss
>> disk operations, etc etc).
>
> The number of times 'b' as discussed here will be hit is negliable. Not
> sure it's worth trying to optimize this.
>
> But the bigger picture 'b' may be worthwhile to optimize a bit, namely
> better management of swapin requests. Currently there is one open disk
> cache handle per concurrent client, should be sufficient with just one
> for all swapin clients.. but that requires the store io interface
> implementation to be cleaned up a bit allowing multiple outstanding read
> operations on the same handle but processed one at a time to avoid seek
> issues..
>
> Regards
> Henrik

I'm hitting the case approximately once every 10-15 minutes on the CDN
reverse proxies. More when bots run through this particular clients
website. It's almost always on these small files (~10K) retrieved
long-distance in reverse proxy requests. They arrive in two chunks
200-300ms apart. swapin race gets lost at some point between the two reads.
Content-Length is available and a buffer can be allocated (or existing one
extended) for memory storage immediately instead of a disk file opened,
modulo the min/max caching settings.
All the other cases (too big for memory, no content-length etc) can go back
to the old file open if need be.

Amos
Received on Mon Sep 28 2009 - 00:04:36 MDT