Re: [squid-users] Squid 3.x very slow loading on ireport.cnn.com

From: Eliezer <eliezer_at_ec.hadorhabaac.com>
Date: Mon, 24 Jan 2011 09:52:23 +0200

well i have found the problem..

it's not your proxy...

your proxy is doing fine cause it's identifying files mimes and stuff=20
like that.

have you ever heard of ZIP BOMB?

well it's not it but it's something like it.

the site itself working fine and the page is getting to your computer in=20
like the 5 first seconds...

but... they are using such amount of Java script that i dont know how=20
even a PIII computer will handle it.

well it's not the point.

the point is that you wont see the page until liek the 50+ element in=20
the page.. so if one of the elements in the site is stuck cause of a bug=20
in the server or what so..

you wont get it.

to make sure of it i uses paros to interogate it and i noticed this stuff=
.

so now the thing i do i allow only html mime... i want you to try suff

the first page is 100KB

wget will get you the page and you can try to look at the source and=20
stuff like that.

the thing is the after the object 13 in the page...

you will get the object:

http://ireport.cnn.com/themes/custom/resources/username-overlay.js

and then the action begins..

so

after the 84 object it takes forever....

   ok so last line in here.

first use wget to get the index.html file

it will take about 1-2 seconds.

then open oit using any browser you want and tell me what happend with=20
squid on...

for me it took a second to show up..

   the same page just from http://ireport.cnn.com/ that loads every thing.=
..

takes to *render* a long time.

*so the guys who asked.. that is the case.*

what i did was to get the page ( i see on the top of the page the RSS=20
feed is here, in firefox)
i stop the page from loading

got into the source

copy the source

paste it in new html file...

load the file in firefox and get it without all the css ... the pictures=20
and every thing but not the look they wanted.

On 24/01/2011 06:35, Max Feil wrote:
> Already did use Wireshark. Here is some more info:
>
> If you look through the traces you'll notice that at some point Squid
sends a TCP [FIN, ACK] right in the middle of a connection for seemingly
no reason. (Attempting to close the connection) The server ignores this
and sends the rest of the data, which Squid responds to with TCP RST
(request to reset) since it now believes the connection to be closed.
>
> From the browser side it seems to be given no notification that the
connection was closed (and indeed I can see no reason why it should be
closed) so it seems to sit around doing nothing as it may have reached
the max connections limit. After about 2 minutes (possibly related to a
persistent connection timeout limit in squid) Squid seems to terminate
all the connections with FIN,ACKs. The browser then seems to realize its
connections are gone and it requests the remaining resources resulting
in a bunch of TCP SYNs followed by the rest of the resources.
>
> Why it does this in the middle of connections we still have no clue,
however turning off server_persistent_connections seems to make it load
fast. However this is probably a bad idea in general...
>
> Max
>
> -----Original Message-----
> From: Henrik Nordström [mailto:henrik_at_henriknordstrom.net]
> Sent: Sunday, January 23, 2011 7:16 PM
> To: Max Feil
> Cc: squid-users_at_squid-cache.org
> Subject: RE: [squid-users] Squid 3.x very slow loading on ireport.cnn.com
>
> tor 2011-01-20 klockan 02:50 -0500 skrev Max Feil:
>> Thanks. I am looking at the squid access.log and the delay is caused by
>> a GET which for some reason does not result in a response from the
>> server. Either there is no response or Squid is missing the response.
>> After a 120 second time-out the page continues loading, but the end
>> result may be malformed due to the object which did not load.
>
> I would take a peek at the traffic using wireshark to get some insight
> in what is going on there.
>
> REgards
> Henrik
>
Received on Mon Jan 24 2011 - 07:52:32 MST

This archive was generated by hypermail 2.2.0 : Mon Jan 24 2011 - 12:00:03 MST