Re: [SQU] Need Info . . .

From: Joe Cooper <>
Date: Mon, 05 Mar 2001 10:32:07 -0600

Your box should very very very easily handle 300 dialups plus a few
DSL's and some other traffic (unless that other traffic and DSL accounts
for two or three times the traffic of 300 dialups).

Is a good start for speeding up a Linux Squid box. Though I don't see
how you could be running into performance problems. Are you sure Squid
is what's slowing down? Perhaps you're saturating your bandwidth? Even
a standard default Squid installation on a box that size should be fast
enough for that load.

I'm guessing you're on a single or dual T1 internet link, correct? A
single disk IDE box when tweaked for performance can handle that kind of I'm guessing there is something wrong somewhere. What does
CPU usage look like during the high load periods? Any errors appearing
in the logs? Is your DNS fast enough to keep up?

Oh, just hit me why you may be slowing down. How big are your
cache_dirs? Every cache object entry is indexed in the swap.state file,
and in memory. So if you have 4 huge cache_dirs your box may be going
into swap. If it goes into swap, then performance will drop to very sad

As for your questions...I've answered them inline with your message:

Bryan Campbell wrote:

> Lo All -
> I have an installation of RedHat 7.0 stripped down, secured, and patched
> up (all the appropriate rpm updates and a 2.4.1 kernel update) running
> the current version of Squid (Version 2.3.STABLE4). I have adjusted the
> file descriptors, configured for local DNS lookups, and adjusted every
> parameter suggested in the FAQ. The machine is an 950 MHz Athlon with
> 768MB of RAM, and the cache dirs are on 4 18GB Ultra 160 SCSI disks. I
> can send along more in depth specs as necessary.
> The traffic consists of approximately 300 dial-ups, a few DSL lines, and
> some office traffic. The redirection of web requests is handled by a
> Foundry Layer 4 switch, and the recommended ipchains commands.
> Yet, under the afternoon, and evening load, the Squid installation slows
> down significantly. So, The following questions are my next step in
> resolving this performance issue.
> Please, assume I have read the FAQ. Some of the following questions can
> and have been answered by the FAQ. However, I am hoping for a more
> concise, and possibly more current digest of the facts as they relate.
> :-)
> TIA!
> 1. What is considered a heavy workload for a Squid server? What can it
> handle?

15Mbps (i.e. 10 T1 lines)...on a very big box, with a very tweaked Squid
and kernel. (Running Linux on x86 or Alpha, or possibly Solaris on Sparc.)

It takes a lot of tweaking and a lot of hardware to handle those kinds
of loads with Squid. Less than that, less work, less tweaking, less
hardware. Less than 4 T1s you can handle with reasonable IDE hardware
and very little tweaking.

> 2. What version (patches, etc . . .) of Squid is recommended for a Squid
> server under heavy workload?

Squid 2.4 running with async I/O or diskd. 2.2STABLE5+hno snapshot is a
tiny bit faster, maybe.

> 3. What are the recommended adjustments to Squid for heavy workloads?

See the article linked above.

> 4. What are the recommended adjustments to the Linux OS to ensure proper
> operation?

As above.

> 5. Is there one OS which runs Squid better than all others?

Linux on high end Intel (AMD, too) and possibly Solaris on Sparc. I run
it on Linux/Intel, and I've never seen a faster Squid than the ones
we've got running at several sites. Henrik had some monster fast Alpha
Linux boxes running Squid at very high loads, as well. FreeBSD with
DiskD is a respectable performer, as well.

But again...for a couple of T1s, you don't need to worry about all this
stuff. Your box should just do it, without even trying too hard. If
it's not, then there is a misconfiguration somewhere.

> 6. What is the most effective redirector for the local machine to pick
> up transparent caching requests forwarded from a layer 4 switch?

IPChains. (Or netfilter in your kernel 2.4.1 case.) This shouldn't
have any measurable impact on performance (I've benchmarked with and
without a redirect rule in place, and the difference wasn't
statistically significant). --
                      Joe Cooper <>
                  Affordable Web Caching Proxy Appliances

To unsubscribe, see
Received on Mon Mar 05 2001 - 16:58:06 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:58:32 MST