Symphony.

Can you please replace index.php with this code: http://pastie.org/855107 and post the output here. This will return the output content length reported via various methods.

So it won’t interfere with front end presentation just log output in /blah?

If I may add a symphony-unrelated experience: I’m dealing with a very similar problem when loading CSS built with CSSCaffold (an enhanced CSS library, worth checking it out). My DOMContentLoaded delay is a pretty constant 15 seconds and is directly related to Content-Length.

The problem was that CSSCaffold set content-length with the uncompressed output, then only adjusted if it was itself doing compression. Since Apache was configured to compress and CSSCaffold was not checking for this case, the Content-Length was incorrect and the browser was waiting for more content before abandonning.

Perhaps the 5 seconds or 15 seconds is just a default value. I’m using Ubuntu Linux 9.10 with Firefox 3.5.8, although the delay was the same on Mac OS X.

JIT Image Manipulation extension seems to be causing my delay in load.. Report from Host is stating CPU load was maxing at 22% on Shared Hosting and stated also that the most accessed files was image.php inside the JIT Extension folder and index.php.. it seems as if no images get cached when using JIT and symphony because the images are requested again when the page is loaded intead of using what is cached.

The increase in load is caused when the page reached the Htaccess rule for the JIT extension in the root of the site. Anyone else find this issue? Thought it might have been one of those adddthis.com js buttons that pulls content from their server into the social media bar.. but alas the CPU load is still reported.

Edit Also I have noticed that the returned Header info in my site as with Symphony-cms.com shows the Expires entry to be in the past! i.e: It expires in 1981!! is this normal or am I not understanding correctly?

This is Returned Headers output for symphony-cms.com from Chrome Dev Tool.

• Cache-Control:no-store, no-cache, must-revalidate, post-check=0,pre-check=0
• Connection:close
• Content-Encoding:gzip
• Content-Length:3079
• Content-Type:text/html; charset=utf-8
• Date:Sat, 13 Mar 2010 21:17:06 GMT
• Expires:Thu, 19 Nov 1981 08:52:00 GMT
• Last-Modified:Sat, 13 Mar 201021:17:06 GMT
• Pragma:no-cache
• Server:Apache/2.2.14 (EL)
• Vary:Accept-Encoding,User-Agent
• X-Powered-By:PHP/5.2.11

Hi moonoo2 — while JIT may have a processing overhead, this problem is specifically about the page headers. Symphony is building and sending the page back in usual speedy times, but the incorrect Content-Length header means that the DOMContentLoaded event in the browser fires too late.

So this isn’t a CPU or server processing issue. If you’ve got problems to that effect, please start a new thread.

Cool :) JIT thread coming up!

So is the Expires: (Returned header) normal to state that it will expire when Back to The future was out?

EDIT Also Alistair - tried your index file and all methods output the same resulting Content-length. Which is a good thing I guess. 12930 or something like that.

So is the Expires: (Returned header) normal to state that it will expire when Back to The future was out?

Setting it in the past means that proxies and client browsers won’t attempt to cache the output, which is important for dynamic content.

tried your index file and all methods output the same resulting Content-length. Which is a good thing I guess. 12930 or something like that.

Okay. That means the content length header is accurate. I was hoping that austinjackson could run it too, since the report was the content length header was much longer than the actual length.

Sorry this took so long. Difficult testing this on a production server. I am getting the same content length for all of your tests:

obgetlength(): 6079 strlen(): 6079 filesize(): 6079

But, I am still getting 2.2k in Firebug.

I am getting the same content length for all of your tests:

That’s a good sign. Can you do a couple of things. Firstly, open up terminal/shell (assuming you are on a *nix system) and use the following command, and have a look at the Content-Length header:

curl -i http://yourwebsite.com/ | less

Secondly, is your server using any output compressions? E.G. zlib.output_compression = on in the php.ini. You can check that by looking at your PHP info. Perhaps the server is compressing the output, but not updating the Content-length header.

I was having this exact same issue, which I narrowed down to the following:

• It happens only on keep-alive connections
• it's the browser not closing the connection when it should
• the 15 or 5 secs delays that some of us experienced is the keep-alive timeout setting of apache (it doesn't happen with nginx)
• I think it's caused by mod_deflate, because when I disabled it everything started working normally again
• I have noticed that in fact the content-length declared in the headers was that of the uncompressed page, but the thing was being gzipped (by Apache)

With Symphony, who's setting the Content-Length header? Apache or Symphony? May it be a case that symphony declares the uncompressed value, and Apache passes the header untouched, along with gzipped content?

Oh-oh buggy boy that mod_fastcgi: https://bugs.launchpad.net/ubuntu/+source/libapache-mod-fastcgi/+bug/381384
I think it's this that's causing the mayhem. It the penalty we have to pay wanting to be cool with php-fpm I guess.