On Wednesday 17 September 2003 20:52, Oded Arbel wrote:
> Hi people - I beg for our forgiveness of the off topic post (well,
> everything here runs linux so its not totally off topic), but I got the
> darnest thing which I can't put my thumb on, still can't figure it out and
> I've ran out of ides.
>
> I have a site, for the sake of the argument lets call it
> http://org.demons.co.il/forum. but its terribly terribly slow - page take
> several minutes(!!) to load.
> At first I thought it was it was network - checked the network monitor, and
> its not.
> Then I said its probably the rendering of the page - put counters on the
> PHP files and they all render in less then 1/10 of a second
> Then I said it's CPU load - but load rarely goes over 0.10
> Then I tries to load the page with links (text web browser), and it flies !
> Then I tried some other clients - all the standard graphical ones work the
> same (real slow). links and links-graphic are fast, as well as any command
> line HTTP downloader I tries. elinks and lynx are again extremely slow.
> running tcpdump on the local machine I can see the request being pushed out
> and the ack on the request packet comming back and then nothing for a
> while, then the client sends FIN and the request again at which point the
> server sends some 10 or so packets for which the client answers with RST.
> then they both wait a while and go at the whole thing again.
Ok, here's an update in case someone is interested - I still don't know why it
happens, but I can fix it - sorta..
It only happens in the forum because the forum is written in PHP and uses
ob_start('ob_gz_handler');
commenting out that line, and everything works perfectly (no gzip support of
course). this is what I think is why everything but links chokes - links
doesn't pertain to support gzip compression, so ob_gz_handler doesn't do
anything for it.
now more funny stuff - output_buffering is off. its the default and I forgot
to change it. so I turn it on and everything still works, then I turn on
ob_gz_handler, and this time I get the response - but its all garbled, like
the browser can't understand the encoding.
I noticed that the content being received from the server when ob_gz_handler
is on is indeed gzip compressed data, but with an additional \r\n at front.
after I traced that to one of the php files and removed it, things started to
work again.
apparently, the browser gets stuck when ob_gz_handler is active and there is
data before the handler is called. this data gets flushed out of the output
buffer and is sent infront of the gzip compressed, but after the headers -
which messes up stuff. additionally, ob_gz_handler waits for the entire page
to render before compressing it and sending it all away in one big chunk -
unlike using zlib.output_compression which isn't affected by whitespace at
the header and is compressing on the fly.
What I don't understand is why I see this as a network error - tcpdumping at
the server I can see the reponse packet being sent out but never getting an
ack. Also - I don't understand why it eoes work after a long time - giving
the browser something like two minutes will allow it to eventually get the
page up. this behavior is not consistant with either network problem or gzip
compression issue.
Weird
--
Oded
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
