[squid-users] Re: performances ... again

GARDAIS Ionel wrote:

> Beside the fact that the hit rate is low, response time are way too long
> for users (cache-misses median service times are around 200ms and
> cache-hits are around 3ms)

----
	Have you tried access without a squid-proxy -- but maybe
using 'socks' (if you need to bridge a firewall), or direct?
	I've done performance analysis on my squid installation a few
times -- cuz not happy with performance...but.. when squid isn't there
and I go through socks, or I setup a machine on the net directly -- I
don't get any faster throughput or response time ... at most, we're
talking differences down in the noise level ...
	One-by-one, I eliminated or upgraded parts that I could -- my
internal net is 1Gigabit.  Tried upgrading to a firewall product that
supported a 100Mb interface (old was 10Mbit&half duplex)...but its
a matter of my DSL not being much faster than yours -- ~2.5-3Mb.
But simple 'ping' times to most servers are 100ms or more.  within
my ISP's network, they are as low as 50-55, but going out, and back
down someone else's network usually adds at least another 50, often
nearer 100, so just ping times alone to many outside destinations
are 100-150, closer to 150 on heavier sites.
	So if a tiny ping packet -- handled by the OS takes
that long -- of course adding web-server application time to that
is going to add 'something'.  So while some outside servers can serve
1-segment packets in the 150-160ms range, most are higher ...
	A TCP_REFRESH_UNMODIFIED might take around 140-150...
But most misses are 400, 600 or more, easily.
	My hits are fast...some coming in at less than 1ms (0 is stated),
but if you have to go to a webserver -- forget it...300-1000 is
typical -- *without* a cache (in my case, anyway).
	The only ways to speedup web pages are to make sure your
clients are issuing multiple requests in parallel -- easily configured
in Firefox, but there  are KB articles (& pay-utils that will set
the values for you, of course) for MS products.  Since I take it that
pipeline requests doesn't work in squid(?) and compression doesn't
work (not that compression would help latency -- only throughput), the
best thing is to make sure your clients can issue at least 8 requests
in parallel at a time -- through your squid proxy and that your
squid-proxy can handle that many connections/client without becoming
a bottleneck.  My proxy usage is often just me -- so no prob, but even
when I have housemates and guests active, squid never seems to be
a bottleneck.