slow loading css on hayes

[tom]

First off -- love the product! Very exciting to work with the Hayes release as it comes out the door, the world has been waiting for this product, you're going to wildly successful, etc..

But I'm encountering a bug with the load times on my test installations. I'm running:

Debian Etch
Apache 2.1
PHP 5.2
MySQL 5.0.22
Hayes C

When I access DekiWiki remotely, certain css files often take 15 sec to load. This doesn't happen when I access DekiWiki locally.

Here's a FireBug screenshot.

http://forums.opengarden.org/attachment.php?attachmentid=27&stc=1&d=1186678677

The culprit files are /skins/common/print.css, and /skins/ace/neutral/_styles.css. (On Hayes B there was also a xinha.css file that loaded slowly). These files load without a problem when accessed directly.

We also have a Gooseberry installation running on the same server, with no problems.

Hoping I'm missing something obvious! (which is quite possible)

[royk]

Hmm, it's nothing obvious ... those are being served directly from Apache, so it's most likely an Apache configuration issue (your attachment is a bit fuzzy, but it looks like images are taking about 1 second to load too?)

you may want to try boosting MaxClients, StartServers, MinSpareServers and your MaxSpareServers in your apache2.conf

when you do a hard refresh, are those 2 css files consistently the slow-loading ones?

[tom]

Working on your suggestions for the apache2.conf right now...

The images are taking up to 3.3 seconds to load.

On a hard refresh, /skins/common/print.css and /skins/ace/neutral/_styles.css are the most frequent culprits. There are times when /skins/ace/neutral/_styles.css doesn't load at all (which messes up display beyond repair). /skins/ace/neutral/css.php and /skins/common/logo/logo.png also sometimes take 15 sec to load. And on the Hayes B release xinha.css regularly took 15 sec to load, but that's not showing up on Hayes C.

[tom]

We adjusted the StartServers setting in apache2.conf from 2 up to 5 and that did it. We're loading in 3 seconds now, instead of 30!

Many Thanks! Now the fun really begins...

[SteveB]

Wonderful! Thanks for sharing the fix.

[tom]

Unfortunately, I spoke to soon when I wrote the problem had been solved. I've now seen the issue replicated on other computers using Mozilla Firefox. This is clearly a client-side problem -- the problem only appears on clients using Mozilla Firefox and certainly not all of them. I have accessed our test installation of DekiWiki Hayes on 7-8 different computers using Firefox, and this problem has shown up on three of them.

We've tried fooling around with the apache2.conf file to no avail -- not suprising, given that is likely a bug related to DekiWiki's interaction w/ Firefox.

Each time it's a css or javascript file -- print.css, css.php, styles.css, _jscripts.php, Xinha.css -- that takes 15 sec load, or doesn't load at all.

On a hard refresh, everything loads no problem -- I got this wrong in earlier post. That would seem to point to some issue w/ the Firefox cache. FWIW, the problem files are caching.

I don't want to report this as a DekiWiki bug because it seems like it's a problem with Firefox, but nothing jumped out at me when I searched the web for info on slow-loading css...

I've attached a couple more Firebug screenshots -- any helpful thoughts will be much appreciated. We've run a gamut of tests on Firefox so far, creating new profiles, fooling around w/ config settings, and no luck so far.

[royk]

because those files are being served directly from apache, we would have to debug at that level.

microsoft has released an awesome tool called fiddler2 which does a great job of detecting network issues - most of us use that instead of firebug now :)

Give it a download at: http://www.fiddler2.com/fiddler2/

You can setup Firefox to use it by going to Tools > Options > Advanced > Network > Settings and selecting "Manual Proxy Configuration". Then load up Fiddler2 and hit your wiki - you can see how much time is spent sending the request for each file, time spent on the server side, and time spent sending it back. If you can dump the output of Fiddler for a full page load, we can get a better idea exactly what's going on (and who's to blame for the delay).

[tom]

OK, I'm setting up fiddler. Got it to work with Firefox. But whenever I try to access a remote site I get the following:

Fiddler: DNS Lookup for google.com failed.

And in fiddler, it's showing up as a 502 result code. Any thoughts? I can't find any documentation for this online.

[tom]

Ok, Fiddler is up and working. Great program. And the good news is, that when running through Fiddler as the proxy I'm not seeing the 15 sec delays loading specific files. Weird.

But I am seeing a protocol violations when loading pages in Firefox.

The most common protocol violation happens every time I load a page, and comes when requesting


GET /skins/ace/neutral/css.php HTTP/1.1
GET /skins/common/print.css HTTP/1.1
or GET /skins/common/_jscripts.php?perms=LOGIN,READ,BROWSE,SUBSCRIBE HTTP/1.1


I see:


Fiddler has detected a protocol violation in session #608.

Response does not start with HTTP. Data:

200 OK

Then there are two other errors that prevent pages from loading, and happen only occasionally, one out of fifty loads. When I request...


GET /@api/deki/site/nav/51/children?dream.out.format=json&width=1600 HTTP/1.1

... or just the wiki page itself, as in ...


GET /Renewable_Energy/Hydropower HTTP/1.1

.. I get:


Fiddler has detected a protocol violation in session #1006.

The Server did not return properly formatted HTTP Headers. Maybe missing altogether (e.g. HTTP/0.9), maybe only \r\r instead of \r\n\r\n?


Then just to spice things up, I also sometimes see this:


[Fiddler] Response Header parsing failed. This can be caused by an illegal HTTP response earlier on this socket, like a 304 response which contains a body.

I'll see if I can dump the output of one of the "Response does not start with HTTP. Data" errors.

[tom]

Here's the fiddler output from a typical page load, where css.php fails to load.

[tom]

And here's a whole kitchen caboodle of loads, in Firefox and IE.

Running through Fiddler, I'm seeing a lot of the same problems with the css files failing to load in IE and Firefox. I never noticed these in IE before.

Note the sixth request from the top -- that's one of the requests where the page doesn't even load.

[tom]

I think this bug has to do with Norton Anti-Virus. When I disable it, pages are loading fine in Mozilla. But when Internet Security is enabled, I get the weird 15 second delay on the css files loading, and errors showing up left and right in Fiddler.

When my Norton Anti-Virus Internet Security is enabled, things look fine in IE (well, relatively fine, given the other IE bugs), but errors do show up on Fiddler. I guess IE just handles the Norton Anti-Virus filter better.

[SteveB]

Roy found a few issues today that he's actively fixing. One of the problems found was that the 'Content-Length' header wasn't set, which meant the contents were sent using 'Transfer-Encoding: chunked' which causes issues for gzipped content.

Details aside, we hope to resolve this with tomorrows update.

Thanks again for all your helpful feedback!