On Sun, 27 Sep 2009 21:16:29 +0200, Henrik Nordstrom <[email protected]> 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
