By jgumpert on

I have a drupal 6.x site on that is painfully slow to load any page even with no load on the server - over 30 seconds per page with normal caching enabled. Granted there are lots of CSS and JS files, but when I inspect with Firebug I can see that there are GETs for certain files that always come in way slower than the rest. Most of the CSS and JS get downloaded in somewhere between 30 and 800 milliseconds. Not great, but within a range that makes sense. Then there are the following CSS files that are off the charts in their slowness - between 35 and 70 seconds each! Here's that list:

  • node.css
  • defaults.css
  • system.css
  • system-menus.css
  • user.css

It seems pretty consistent each time I load a page. Anyone know what would make these 5 go so slow and the rest show up 'normally'? It's not the file size. The contents of the files look normal. I didn't spot anything in the headers but I could have missed something.

Any suggestions appreciated!

⋅ Categories: Drupal 6.x

Comments

pbarnett’s picture

pbarnett commented

Have you tried enabling CSS aggregation at /admin/settings/performance ?

jgumpert’s picture

jgumpert commented

Thanks for the suggestion.

So I've just done that (added proper permissions to the files dir) but I get a similar response with these aggregated files - three css files - 1.7 KB downloads in 42ms, 42KB in 7.44sec, and 714bytes in 17.03 sec! And the majority of that time is attributed to "waiting" according to firebug. Similar issue for Javascript - the one big JS file is 159KB in 24.43 sec, nearly all of that waiting.

One possibility could be it's waiting for something external, but I can't think of what that might be. And I haven't seen anything external in any of the slow JS or CSS files.

Anonymous’s picture

Anonymous (not verified) commented

Which theme are you using? Does the same problem occur with Garland?

jgumpert’s picture

jgumpert commented

I'm using a custom theme based off zen (I think). I will give this a try a bit later and report back. Thanks!

Anonymous’s picture

Anonymous (not verified) commented

You're welcome. :-)

If that doesn't work, also check your modules. And if turning them off solves your problem. Then turn them on one by one, and see if the problem starts again.

You haven't made any changes to core code, or added any code elsewhere?

jgumpert’s picture

jgumpert commented

So I've tried running some of the slow pages in Garland and it's the same issue. These same CSS files are taking 15 to 45 seconds to load still. I disabled CSS/JS aggregation to get the more detailed view of things. With aggregation on it was still really slow to pull down the aggregated files.

I'll start picking off modules next and see if I can find anything out that way.

Anonymous’s picture

Anonymous (not verified) commented

So I've tried running some of the slow pages in Garland and it's the same issue.

This is only happening on some pages or on all pages? If on some, what's different on those pages? Is there a pattern?

Is it occuring in different browsers, or just some?

Are you using a local set-up, or is this occuring online? or both? What kind of server set-up are you using?

Edit:

I disabled CSS/JS aggregation to get the more detailed view of things. With aggregation on it was still really slow to pull down the aggregated files.

Did it improve when you turned aggegration off? Does the problem occur when cache is turned on?

jgumpert’s picture

jgumpert commented

It seems to be happening on all pages - pages with views, with lots of blocks, with just a single node and no views blocks. Any page that pulls down the offending CSS files I suppose, but that's an assumption really.

I was first seeing this on a hosted test server but then I turned back to a local instance of the same site and I noticed it was doing it here too - only difference locally was that the regular css and JS file downloads were 4 to 5ms and the offending files were 1.5 seconds each, but it was the same files. I hadn't noticed earlier because the delay was pretty short.

I started turning off all the modules I could that wouldn't break the site and while I haven't exhausted that approach yet I haven't found a magic module. The remaining modules to test will start breaking the site when I turn them off, so that is a whole new challenge.

CSS/JS aggregation didn't seem to matter either way,

One interesting thing with normal cache - first time a page loads these CSS files take forever. If I reload the page they seem to be cached because they load up quickly along with all others. But then if I browse away and return to that same page (or any other page that wants those same slow CSS files) they get requested and re-loaded with same the long wait. All CSS files have a '304 Not Modified' status according to Firebug and that doesn't seem to change over time.

I wonder if there are better ways to debug this with Firebug or a similar tool to identify more about the wait time? The http headers for a fast and slow CSS request look virtually identical - the only variation I see is the Etag and the If-None-Match values. Here it is in case it is useful:

Response Headersview source
Date Sat, 21 Aug 2010 02:29:15 GMT
Server Apache
Connection Keep-Alive
Keep-Alive timeout=15, max=99
Etag "98938-edc-47f346e46c000"
Request Headersview source
Host 111.222.333.444
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 GTB7.1 ( .NET CLR 3.5.30729; .NET4.0C)
Accept text/css,*/*;q=0.1
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Referer http://test.site.com/product/apple
Cookie SESSa8dcf99c0b1360d253789a9cfc6f8a84=6ec83486d3fd6c6ee3538e2da11fd428; has_js=1
If-Modified-Since Wed, 10 Feb 2010 00:51:12 GMT
If-None-Match "98938-edc-47f346e46c000"
Cache-Control max-age=0

Response Headersview source
Date Sat, 21 Aug 2010 02:22:17 GMT
Server Apache
Connection Keep-Alive
Keep-Alive timeout=15, max=100
Etag "9567f-2724-47f346e46c000"
Request Headersview source
Host 209.20.88.72
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 GTB7.1 ( .NET CLR 3.5.30729; .NET4.0C)
Accept text/css,*/*;q=0.1
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Referer http://test.site.com/about
Cookie SESSa8dcf99c0b1360d253789a9cfc6f8a84=6ec83486d3fd6c6ee3538e2da11fd428; has_js=1
If-Modified-Since Wed, 10 Feb 2010 00:51:12 GMT
If-None-Match "9567f-2724-47f346e46c000"
Cache-Control max-age=0

jgumpert’s picture

jgumpert commented

One other random thought on this - any of these slow CSS files can be downloaded directly through a browser in a normal amount of time - some milliseconds, not 30 or 40 seconds. So the question I think is what mechanism or interaction is different when downloading these CSS files with a browser as links in an HTML page?

jgumpert’s picture

jgumpert commented

Still fighting with this one...I'm looking at the Apache access log and when I do a 'tail -f' I see that the slow files are not getting logged by apache with 200 or 304 codes until the end of the 30 second delay. Does this mean the browser is the one sitting on the requests for these CSS files until the end of this time?

Firebug is telling me that for a sample slow CSS file, it's taking 43ms Connecting, 1ms Blocking, 0ms Sending, and 17.43 sec Waiting. I guess that means the request is waiting around on the server side after the first 44ms. Where? I don't know.

Can anyone confirm this or set me straight on what Firebug is explaining with the Net tab?

rodb’s picture

rodb commented

We are having the exact same issue as you on our Apache 2.0.63.

Did you find a solution?

Anonymous’s picture

Anonymous (not verified) commented

Is the problem occurring when your logged in, out, or both?

ayesh’s picture

ayesh commented

You can use Chrome's webmaster tools(I mean tools integrated in chrome.exe) to get very detailed data and analysis of CSS files.

What's new and changing in PHP 8.4

rodb’s picture

rodb commented

Ok I figured this one out.

Once I started looking at the page output with http://www.fiddler2.com/fiddler2/ I could see messages like this:

Fiddler.Network.ProtocolViolation - #5: Support Content-Length mismatch: Response Header claimed 7162 bytes, but server sent 3701 bytes.

It seems that whatever was doing the compression wasn't doing the job properly, so I went through and commented out all mod_deflate compression in .htaccess

Firebug/yslow still showed the pages were being compressed so I checked php.ini and also commented out zlib compression like so:

# zlib.output_compression = On

Once that was done, the problem went away. The browser was pausing for 15 seconds each time it got a mismatched header response while it waited for the extra data it was never going to get. I guess it must be a bug in php or something in cerberus itself.

Now to figure out what the problem is with compression so we can turn it back on!

Thanks for all who made suggestions and offered support.

ayesh’s picture

ayesh commented

Glad to hear that you are figuring out...

What's new and changing in PHP 8.4

rodb’s picture

rodb commented

We figured out the problem with compression eventually but I neglected to post it back here. This is the configuration that ended up working for us:

Initially mod_deflate only appeared to be compressing plain text content, even though we had the directives set to compress all content.

Oddly enough, the issue appeared to be related to either the Expires header not being set, or because ETag was set. I'm not sure which, but the solution was to unset ETag and set proper long term expiry on the relevant content as follows: (put this in your .htaccess file or apache config file (/usr/local/apache/conf/httpd.conf on my server)

################################################## ###
# CONFIGURE media caching
#
Header unset ETag
FileETag None

Header unset Last-Modified
ExpiresActive On
ExpiresDefault "access plus 2 months"
Header set Cache-Control "public, no-transform"

#
################################################## ###

Once I implemented the above, then mod_deflate started working on all the css and js content as well. Here is the code I use for mod_deflate, also in .htacess, or the apache conf file:


SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ \
no-gzip dont-vary
SetEnvIfNoCase Request_URI \
\.(?:exe|t?gz|zip|bz2|sit|rar)$ \
no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary

Hope this whole post is of some use to someone else in the future.

cheers, Rod

CzarnyZajaczek’s picture

CzarnyZajaczek commented

Had similar problem, but not always delayed files were the same. Some files (ie. theme/field.css ) were often delayed but sometimes others.

Disabling compression and mod_deflate didn't helped. Just disabled KeepAlive in apache conf - and works great ;)

Maybe setting MaxKeepAliveRequests to lower value (I had set 100) would help too, but it is only testing environment and current settings fits my needs.