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

Could you possibly give us the pac script you are using? I once thought that using the option of DNS does not resolve use proxy, else go direct, as internal clients can't resolve outside DNS. This caused a very similar symptom as you are seeing as clients had to wait for local DNS timeouts before going through the proxy on every page.

Thanks,
     Dean Weimer
     Network Administrator
     Orscheln Management Co

-----Original Message-----
From: Ionel GARDAIS [mailto:ionel.gardais_at_tech-advantage.com]
Sent: Friday, June 06, 2008 12:55 AM
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] RE: performances ... again

We are using a pac script, mostly with Windows XP clients ...

@Dean : the second page does not load faster than the first one.
"Browser repsonse time" are much better early in the morning (with less
connection obviously). When a blank page takes too much time to load,
doing a "refresh" or revalidating the URL in the address bar often
"unlock" page loading and the page is displayed with a good response time.

I'll try to investigate if DNS is involved and maybe find a workaround
to the pac autoconfiguration to do transparent proxy.

Ionel

Ritter, Nicholas wrote:
> I had a problem similar to this at another job site a coulple of years ago. The clients were windows xp machines, and they were using wpad/pac style configuration. The fix was transparent caching.
>
> -Nick
>
>
> -----Original Message-----
> From: Dean Weimer [mailto:dweimer_at_orscheln.com]
> Sent: Thursday, June 05, 2008 1:53 PM
> To: GARDAIS Ionel; squid-users_at_squid-cache.org
> Subject: [squid-users] Re:[squid-users] performances ... again
>
> How are your browsers configured to use the proxy? Manual, wpad script, transparent?
>
> Could be a problem with discovering proxy settings.
>
> What about a second page on the same server, ie. http://some.domain.com then http://some.domain.com/nextpage.html? Could be a DNS response issue, perhaps your first server is timing out, and the clients have to wait for the second to respond. If the second page comes up right away, this would be a good indicator of that. As Squid would have cached the DNS lookup from the first request.
>
> Most servers are not going to have a 12Mb/s of bandwidth is a decent chunk, I wouldn't expect to see that maxed out all the time, because you are averaging under 2Mb/s in itself is not cause for concern. The fact that you are hitting it on large downloads means the link is performing well.
>
> I am seeing about 180ms median response time on misses and 5ms median response time on hits, 87ms response time on DNS Lookups. The server is running 2G cpu and 1G ram, with an average of 900 req/min. The server is servicing about 500 clients connected behind 2 T1 lines. Both lines are consistently running at 1.2 to 1.5Mb/s from 7am to 6pm when most users are at work. Disk cache is 8gigs on the same disk as system, which is actually a hardware mirrored ultra 160 10K SCSI disks, (Not ideal, as I have learned a lot more since I first built this system), but the performance is excellent, so I haven't found cause to change it. The server is running FreeBSD 5.4, squid the cache and logs are installed on their own mount point using ufs file system, Mount point is on a single Disk slice encompassing entire hard drive, and to top that off, the file system runs about 90% of capacity, yet another no no.
>
> Thanks,
> Dean Weimer
> Network Administrator
> Orscheln Management Co
>
> -----Original Message-----
> From: GARDAIS Ionel [mailto:Ionel.Gardais_at_tech-advantage.com]
> Sent: Thursday, June 05, 2008 12:11 PM
> To: chris brain; squid-users_at_squid-cache.org
> Subject: [squid-users] RE : [squid-users] Re:[squid-users] performances ... again
>
> Hi Chris,
>
> The internet link is not congested.
> As I wrote, we use less than 2Mb/s of the 12Mb/s we can reach (but yes, upload seems to be limited to 512Kb/s (somewhere around the maximum of the line), this might be a bottleneck).
> When downloading large files (from ten to hundereds of megabytes), the whole 12Mb are used (showing a 1100KB/s download speed).
>
> After rereading my post, I saw that I did not finish a line :
> "[...] cache-misses median service times are around 200ms and cache-hits are around 3ms" but we often see a 10-second lag for browser to start loading the page.
>
> Ionel
>
>
> -----Message d'origine-----
> De : chris brain [mailto:chris.brain_at_wanews.com.au]
> Envoyé : jeudi 5 juin 2008 18:34
> À : squid-users_at_squid-cache.org
> Objet : [squid-users] Re:[squid-users] performances ... again
>
> Hi Ionel,
>
> Your performance dont look that bad. Our stats roughly work out to be :
>
> 1000+ users
> NTLM auth
> Average HTTP requests per minute since start: 2990.8
> with max 30% hits. (so your hits look coparable to us.) Our cache miss service time averages to about 160ms and cache hits service time about 10ms running IBM blade P4 3G cpu 1Gb ram. mirrored drive.
>
> Our links can get quite congested and we dont get complaints about the performance.
>
> Are you having internet link performance issues?? are you monitoring it
> (snmp/netflow) ?
>
> chris
>
>
>
> ------------------------------------------------------------------------------------
> West Australian Newspapers Group
> ------------------------------------------------------------------------------------
> Privacy and Confidentiality Notice
>
> The information contained herein and any attachments are intended solely for the named recipients. It may contain privileged confidential information. If you are not an intended recipient, please delete the message and any attachments then notify the sender. Any use or disclosure of the contents of either is unauthorised and may be unlawful. Any liability for viruses is excluded to the fullest extent permitted by law.
>
> Advertising Terms & Conditions
> Please refer to the current rate card for advertising terms and conditions. The rate card is available on request or via www.thewest.com.au
>
> Unsubscribe
> If you do not wish to receive emails such as this in future please reply to it with "unsubscribe" in the subject line.
>

-- 
Ionel GARDAIS
System-Network Engineer