Re: [squid-users] Tweaking Squid for speed, not max requests

On Thursday 30 August 2001 09:29 am, Joe Cooper wrote:
> Don't use async-i/o and put all the RAM you've got handy in the box.
> Raising cache_mem might help. Other than that, you're throwing a ton of
> hardware at the problem--I don't think you'll see any performance issues.

Hmm. I went with async-I/O with the expectation that it would better
utilize the 2 processors on my box. Did I ASSume incorrectly?

> Henrik has mentioned in the past that async I/O will actually lead to
> slightly higher latency than not when used on a low load network (though
> I don't have any experimental data to back it up--but what Henrik says,
> I believe). DiskD might be a good compromise, but we'd have to ask
> Henrik or Adrian, since they know more about Diskd than I do. But async
> i/o is really only needed when you're seeing 30+ requests/second, maybe
> more on a system as big as yours.

Well, you won't find me questioning Henrik's Squid facts, either. :-)

I haven't gone with DiskD because my cache is on a single disk drive. My
understand, from a question asked previously on this list, is that DiskD is
for handling multiple drives concurrently.

Regarding the number of requests/second, the nature of Web access makes
Squid bursty. My number of requests averaged over, say, a 24-hour period
would look absurdly low to someone used to a large corporate environment.
Though many per-second snapshots would show zero Squid activity, the
requests/second can exceed 30+/sec just be having 2 users each view a
single Web page. (Example: a main HTML document, with another HTML
document as a windows pane, plus a dozen graphics.)

Thanks for the response.
Received on Thu Aug 30 2001 - 08:44:08 MDT