Re: commloops cache digest code works

On Sun, Feb 24, 2002, Joe Cooper wrote:

> Stability is the primary purpose of this testing, and on that count it
> is definitely very solid. I forgot that recent Polygraph versions don't
> play nice with the datacomm-1 workload and never shutdown--and you may
> recall that the working set in datacomm-1 grows infinitely throughout
> the test. So at 11.92 hours into the test, the box is still holding
> together very nicely--14.28GB is the current fill size (and we've got a
> single 4GB cache_dir). Hits at this point are about what one would
> expect from a too small cache_dir for the test (35%, roughly). Error
> count is a lovely '2'. Yep, two errors in twelve hours of too much load.

I wonder what those two errors were.

> So, it looks very good so far. We're still running after nearly twelve
> hours, response is still good, and the underlying OS is still usable
> (not usable for much--CPU is at 2-4% idle). I've hit no weirdness on
> the client side either.

Good.

> I guess I should be poking at range request tickling things to really
> know if someting got broken, correct? (I know range handling has gone
> away temporarily, correct? So we always get the whole object, or do we
> not cache range requests at all and pass them through?)

If its a range request then the request is marked uncacheable and passed through.

> I'm going to see about turning on the checksums in Polygraph to insure
> that data is coming through uncorrupted. My measly three or four
> browsing requests per minute won't necessarily show up any bugs on that
> count, but maybe a few thousand every hour will.

Yup.. that will be an interesting test. Can you let me know how it goes,
and what you've done to the config to test that one out?

Anyone else? Bueller? Bueller?

Don't worry about the speed difference being in your head - you'll
see the speed difference eventually, I'm just not sure if it'll be
under Linux to begin with. :)

Adrian
Received on Sun Feb 24 2002 - 17:42:11 MST