On Sat, 5 Feb 2000, Henrik Nordstrom wrote:
> Sounds very much like you have read my discussion on Squid-dev some
> (several) months back.. archive of the discussion thread available from
> my Squid pages.
Thats exactly what happened. :) After I though about it for a while I
figured it was a perfect solution so I went ahead and did it.
> > Honestly, I can't imagine anything that could be more effecient than COSS.
>
> That is a brave statement, especially considering that different people
> put different meaning into the word efficient. We do however seem to be
> aligned along the same lines here. It looks like you have in fact
> implemented what I have been planning on doing, or at least very close
> to. ;-)
True enough, but I feel safe enough making the statement given the large
amount of thought and effort I've put into it. Actually, I made the
statement to encourage others to say "uh, no, here is a better way" but no
one has so maybe I'm right. :)
> > - typical write case is 1 seek/write per 100 objects (assuming membuffer
> > size of 1MB and 10k average object size).
>
> This worries me a little. There is an issue of starvation for readers
> there. You probably want to tickle out the write data in chunks sized to
> match your read latency requirements. This also applies to large hits
> where you do not want one large hit to have a too large impact on the
> latency of other concurrent hits. Sometimes a few seeks more helps to
> improve the over all performance.
Yes, true. COSS doesn't handle really large objects too well, thats one of
the things I'm working on now. The hack I have in place right now is that
UFS handles large objects (which works out ok). However, I don't want
to require people to have a UFS store and a COSS store, so I'm working to
fix that. Large objects will probably be handled much like they are in
UFS (small chunks read/written). This does result in two code paths, which
sucks, but its the best I've been able to come up with.
> You didn't have much cache did you? Or have you changed your version of
> Squid not to use a in-memory index of the cache content?
I was running the cache from empty for about 10 minutes, just to see if it
would hold up under a load of x requests/second.
/-----------------------------------------------------------------------/
/ Eric Stern - Industrial Code & Logic Inc. - (519) 249-0508 /
/ http://www.indcl.com /
/ WebSpeedWare - web caching doesn't have to be expensive! /
/-----------------------------------------------------------------------/
Received on Mon Feb 07 2000 - 10:45:44 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:21 MST