Re: [UNIXS] Proy servers (fwd)

"Stephen R. van den Berg" wrote:
>
> Duane Wessels wrote:
> >Here's the condensed version:
> > Squid 2.2.STABLE5 on Linux with async I/O
> > 50 req/sec
> > 55% hit ratio
> > 1.52 sec mean response time
>
> A tad bit high mean response times, I think.
> How does that compare with these real-life results?
> To wit:
>
> [ Note: The byte hit ratios are a bit off now, at peak usage, they're
> about 30%-35%.
> I know median-service-time is not the same as mean-service-time,
> but the minimum service time for a hit, is around 0.053s,
> comparing this with the dcomm-1 results, I see Cobalt specify
> a mere 1.98s; what did your test come up with?
> And why is it so much higher?
> -- SRB

Well, on a real proxy array (2.2S3 - lightly patched, linux 2.0.36,
proxy-auth + relentless filtering with redirectors) we peak at around
70-75 requests per second, with an average 61% hit rate (41% by bytes),
and an average mean response time of 0.7 seconds. I'm not saying that we
didn't have to work to get it there, though. This is real traffic from
real users. Still working at cranking it up...linux 2.2 looks like quite
a good bet, as soon as some SMP issues and certain hardware drivers
stabilise...some of our hardware doesn't have stable 2.2 drivers yet.

Yesterday, we _did_ manage to jam one of them up, but good...the
incoming request rate was on the order of 90-100/second, and the
service-times shot up, and things began to bog down. Still doing
post-mortem analysis on the logs, but it looks like what happened was
that (with the incoming request rate exceeding the handling capacity)
the number of simultaneous connections climbed, causing further
overhead, and shortchanged the filtering and authentication processes
(who are large CPU consumers). This further exacerbated the problem
until we hit a mean service time of around 11-12 seconds, which
persisted until the incoming request rate had dropped below the hanling
capacity for a length of time (around three times the mean-service
time).

I'm not yet quite sure how to avoid this, but I have some ideas about
having the helper apps call sched_yield() about halfway through certain
CPU-bound routines, to help share the cycles...I might be talking crazy,
though. Some experiments are in order.

D
Received on Tue Oct 19 1999 - 20:47:45 MDT