I'd start with tcpdump'ing on the client and server-side.
15 minutes sounds like the connection lifetime was reached.
I'd certainly be interested to find squid "losing" a connection.
Adrian
On Wed, Mar 12, 2008, Ivor.Gibbon@kent.gov.uk wrote:
> Amos,
> Just a refresher to bring this up again as it's still occurring.
>
> I'm actually running 2.6.17 not 2.5.17 (typo - sorry).
>
> Please let me know if there's anything else I can supply to help debug
> this.
>
> Thanks,
> Ivor.
>
> > -----Original Message-----
> > From: Amos Jeffries [mailto:squid3@treenet.co.nz]
> > Sent: 30 January 2008 21:39
> > To: Gibbon, Ivor - CED
> > Cc: squid-users@squid-cache.org
> > Subject: Re: [squid-users] CTRL-F5 timeout problem
> >
> > > Generally Squid is working fine, except that users with Internet
> > > Explorer (seems not to be a problem in Firefox) sometimes encounter
> long
> > > delays (15 minutes) when they force a refresh using CTRL-F5 and the
> page
> > > is truncated when they do get it back. Sometimes the problem occurs
> > > immediately, sometimes it may need up to 15 CTRL-f5's before it
> occurs.
> > >
> > > I'm running Squid 2.5.17 on windows 2003 server with three Zopes in
> a
> >
> > Well, there are a LOT of known problems with IE and modern web
> servers. If
> > its critical for you, try using the latest 2.6 and all the many
> > compatibility fixes that have been found and fixed since 2.5.
> >
> > > load balanced configuration using ICP:
> > > *********snippet
> > > acl in_knetpool dstdomain knetpool
> > >
> > > cache_peer 10.110.7.111 parent 8001 9980 no-digest no-netdb-exchange
> > > name=port8001
> > > cache_peer 10.110.7.111 parent 8005 9981 no-digest no-netdb-exchange
> > > name=port8005
> > > cache_peer 10.110.7.111 parent 8010 9982 no-digest no-netdb-exchange
> > > name=port8010
> > >
> > > cache_peer_access port8001 allow in_knetpool
> > > cache_peer_access port8005 allow in_knetpool
> > > cache_peer_access port8010 allow in_knetpool
> > >
> > > cache_peer_access port8001 deny all
> > > cache_peer_access port8005 deny all
> > > cache_peer_access port8010 deny all
> > >
> > > # THE FOLLOWING DIRECTIVE IS NEEDED TO MAKE 'backendpool' RESOLVE TO
> > > # THE POOL OF CACHE PEERS.
> > > # peer balancing: uncommented next two lines
> > > never_direct allow all
> > > icp_access allow all
> > > *********end snippet
> > >
> > > The 15 minute timeframe suggested a read_timeout and reducing this
> > > parameter to 5 minutes caused the truncated page to be returned in
> only
> > > 5 minutes.
> > >
> > > Some judicial use of a packet sniffer suggested that Squid had ICP'd
> the
> > > Zopes and received the page's entire HTML from a Zope (within 3
> seconds)
> > > before starting to deliver it to Internet Explorer. Partway through
> > > sending it to IE, Squid had sent a smaller than usual (622 bytes
> rather
> > > than 4150) http packet to IE (and IE had acknowledged it) and then
> no
> > > further data was sent until Squid timed out (logged a httpTimeout).
> IE
> > > then requested other items in the page (CSS, images etc) before
> > > displaying a truncated page (HTML truncation matched the last
> content
> > > from the small data packet sent by squid).
> > >
> > > Does anyone know why this is happening and what I can do to fix it?
> >
> > Try a more recent squid, the behaviour will likely be different and we
> can
> > then trace it through the codebase and possibly fix if its a true bug.
> >
> > Amos
-- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -Received on Wed Mar 12 2008 - 05:46:18 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Apr 01 2008 - 13:00:05 MDT