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]