RE: Cacheoff results published.

> "Chemolli Francesco (USI)" wrote:
> >
> > [cut]
> >
> > > Our box was a Thunderbird 800, with 3 7200 RPM
> > > disks, and 512MB of RAM. We couldn't handle more than 30
> reqs/sec on
> > > hardware that size. We've got our work cut out for us, eh?
> >
> > I am quite puzzled though, those results strike me at being
> quite low.
>
> Ever tried a polymix-3 load? It's a very tough workload,
> especially for
> Squid. (I assume because it's the cache Alex and Duane know best it
> seems to hit Squid the hardest...we lost about 15-20% from
> Polymix-2 to
> Polymix-3, whereas the best estimate of several ICS folks of their
> lossage was only about 10%.) A Polymix-2 load on this box will run at
> 140...possibly more.

Sure. I just wanted to give some real-world results, with all
the caveats that this implies. It's funny though how a benchmark
designed to emulate real-life yields much worse than real-life :-)

> You'd probably be expecting too much. While the extra disks
> does make a
> difference, you'll max out at well before 150 under polymix-3
> load--and
> you'll see severe hit lossage long before that (we're talking
> 35-40% hit
> ratio when under moderate loads, I've done benchmarks with DiskD). In

I have a count-hit ratio under 20%, byte-hit ratio between 50 and 60%.

> fact, it sounds like you've got a box specced almost precisely like
> Duane's cacheoff box that did 130. You'll probably gain about 15-20%
> over that by using ReiserFS, but ReiserFS is somewhat harder
> on CPU...so
> your CPU tends to become a limiting factor at some number of drives (3
> for async, probably 4 for diskd).

Hm... if the OS handled processor affinity well, it should happen that
squid runs on one processor while the kernel and diskd's run on the other.
But processor affinity becomes noticeable when you reach CPU load
saturation.

> Besides...You've also got a lot more hardware than our tested box. 5
> SCSI drives is a far cry from three UDMA drives.

actually the SCSI drives are 6, but one is used for OS, logfiles etc.
Pity that all of them are on the same (wide) SCSI channel. While I don't
think
it could be a bottleneck throughput-wise (I handle 1.5 Mbps peak),
it might add some latency due to SCSI bus contentions.

> Squid is a lot of great things, but don't accuse it of being
> fast. ;-)

Reasonably fast sounds good.

> Also worth noting is that the simulated environment includes
> delays that
> cause file descriptors to run at well over 1000...I think our box was
> topping 2000 in the peak phases.

That could be an important factor. I heard that poll is one of the biggest
CPU hogs in squid. The bigger the FDset, the more it hogs.
This is why I explicitly specified my FD usage info.

-- 
	/kinkie