RE: [squid-users] Slow connect times

I'll try to answer both emails at the same time.

First, the NTLM helpers. I have squid configured for 10. The stats show the
range going from over 2000 on the 1st helper down to 12 on the 10th, with the
first 5 having 98% of all requests. If having more is not a major resource
issue I will certainly increase them if that will have a positive effect.

Second, traffic to squid right now is very low. I only have about 15 users
testing it, compared to several hundred running via the MSProxy. We are on a
UUNet T-1. Squid is running on RedHat7.3, clients are W95, W98, WinNT, & RH7.3.

Results this morning are great. I tested many sites and did not experience a
single delay. Is there a possible relationship to the amount of time squid is
running?

I certainly appreciate the help. If squid continues to perform like it has this
morning, we can kiss MS goodbye.

Thanks, Tim

-----Original Message-----
From: Henrik Nordstrom [mailto:hno@marasystems.com]
Sent: Tuesday, September 03, 2002 7:26 PM
To: Tim Price
Cc: squid-users@squid-cache.org
Subject: Re: [squid-users] Slow connect times

I missed the small detail that you are using NTLM. NTLM won't work at
all if client side persistent connections are turned off.. (MS design
error)

If only the first request attempt of a NTLM authenticated connection
is slow then perhaps you have too few NTLM helpers for the request
load. Try inspecting the helper usage status via cachemgr.

Regards
Henrik

On Wednesday 04 September 2002 00.48, Henrik Nordström wrote:
> Setting "client_persistent_connections off" should not stop
> anything. The only effect of this should be slighly slower average
> request times.

> > The access log doesn't show any big time lags between records for
> > the same request. On the slow connects the first entry is the
> > DENIED for lack of NTLM, but then back and forth DENIED - MISS -
> > HIT will follow with only fractions of a second elapsed. I can't
> > tell whether there is a lag before the first record hits the log
> > compared to the actual request.
Received on Wed Sep 04 2002 - 07:36:44 MDT