> After receiving numerous messages about Squid's hunger for memory,
> I spent a couple of days hacking up a version which writes immediately
> to disk. It is probably inefficient to the other extreme--all objects
> are written to disk. Uncachable objects are promptly removed.
>
> This code seems to have a number of bugs still, but if you want
> to try it out, it can be found at:
>
> ftp://squid.nlanr.net/pub/Testing/squid-1.1-novm-src.tar.gz
>
> You certainly should not replace your existing squid installations with
> this one. But I'd be interested to hear from people concerning its
> perceived performance. And of course any bug fixes would be wonderful.
Pushing everything out to disk will be slower but not by a large amount.
Using asynch disk I/O will also help heaps there. I've practically finished
debug/testing asynch I/O here at Connect and it is a large performance win
although CPU gets chewed doing frequent polling when requests are outstanding
(roughly 50% - up from 25% using non-async I/O on our boxes).
We found major memory wins by switching malloc libraries. Libc malloc and
GNU malloc simply cannot cope with squid's memory allocation patterns and do
a VERY poor job when memory runs low. We gained a factor of 4 performance
in low memory situations just by changing the malloc library. Unfortunately
the malloc library we used is not in the public domain...
Stew.
-- Stewart Forster (Security and Web Proxy Cache Administrator) connect.com.au pty ltd, Level 9, 114 Albert Rd, Sth Melbourne, VIC 3205, Aust. Email: slf@connect.com.au Phone: +61 3 9251-3684 Fax: +61 3 9251-3666Received on Mon Jan 06 1997 - 21:03:36 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:34:00 MST