Last modified: 2005-01-11 17:18:11 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1230 - GET /wiki/common/common.css take 168 seconds
GET /wiki/common/common.css take 168 seconds
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2004-12-29 23:05 UTC by Looxix
Modified: 2005-01-11 17:18 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Looxix 2004-12-29 23:05:11 UTC
It seems that some of the CSS files take a terrible long time to be retrieved.

This evening the wikis were slow by moment and I had some indication the it was
because of the CSS files.
A test confirm this very clearly.

Test setup:
Internet connection: ADSL 
Browser: moz 1.5 on Linux, cache disabled for the test
Wiki prefs: standard skin

Test: acces the page and
capture the frame via ethereal.

* the main page is quickly retrieved (~0.5 sec)
* then a few css files taking each ~0.2-0.3 sec to be retreived
* the /w/index.php?title=MediaWiki:Standard.css&action=raw&ctype=text/css take
30 seconds !
* and /skins/common/common.css 168 seconds !
* finaly the image of the logo take again a normal 0.2 seconds to be downloaded

If someone is interrested I have kept the capture file.

I don't really understand the problem, are these files served by other servers
than the normal ones ?
Can something be done for this ?
Can this be one of the cause of slowness ?
Comment 1 JeLuF 2004-12-30 00:34:41 UTC
We had some performance issues with some servers today.

Did you repeat your test several times? Was the result reproducible?
At which time of the day did you perform your tests?
Comment 2 Looxix 2004-12-30 02:40:01 UTC
I did the test a bit before I send the bug report, the capture is dated from
Wed, 29 Dec 2004 22:26:36 GMT

Yes indeed at this moment the server was by moment slow (but it was after that
Jamesday restarted the apaches).
At this moment the behaviour was reproducible but I didn't chechk it it was the
same files that caused the problems.

Now the problem is not so easily reproducible and I'm concinced that it doesn't
depend on these particular files.
But I can still reproduce it sometimes (say 1 on 10 trial or so).

I have checked more carefully afew of the capture files and the first long
retrieve always appears a bit after 30 seconds after the first frame.
It seems like this 30 sec is a timeout expiration.
For exemple, with a new test (Thu, 30 Dec 2004 01:19:29 GMT),
trying to geténomène,
first column is the timeing in seconds:
00.000000 -> GET /wiki/Ph%C3%A9nom%C3%A8ne HTTP/1.1
00.414917 <- HTTP/1.0 200 OK
             Expires: -1
             Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
             X-Cache: MISS from
             Connection: close
00.572695 <- (last packet)
00.573043 -> GET /skins/common/wikiprintable.css HTTP/1.1
00.774114 <- HTTP/1.0 200 OK
             Cache-Control: max-age=2592000
             Expires: Sat, 29 Jan 2005 01:19:30 GMT
             X-Cache: MISS from
             Connection: keep-alive
             (only packet)
00.777491 -> GET /skins/common/wikibits.js HTTP/1.1
30.669307 <- HTTP/1.0 200 OK
             Cache-Control: max-age=2592000
             Expires: Sat, 29 Jan 2005 01:20:00 GMT
             X-Cache: MISS from
             Connection: keep-alive
30.960891 <- (last packet)
30.972050 -> GET
31.219501 <- HTTP/1.0 200 OK

31.358161 -> GET /skins/common/sticky.js HTTP/1.1
61.122860 <- HTTP/1.0 200 OK
             Cache-Control: max-age=2592000
             Expires: Sat, 29 Jan 2005 01:20:30 GMT
             X-Cache: MISS from
             Connection: keep-alive
61.253231 <- (last packet)
61.260043 -> GET /skins/common/quickbar.css HTTP/1.1
91.665497 <- HTTP/1.0 200 OK
             Cache-Control: max-age=2592000
             X-Cache: MISS from
             Connection: keep-alive

91.668390 -> GET /skins/common/wikistandard.css HTTP/1.1

from this point the browser seems to have launched several threads and
the following of the requests/replies is a bit more complicated,
but no further delay of 30 seconds occurs and at 92.903849 everything was retrieved.

Hope this help.
Comment 3 Colin Pitts 2004-12-30 02:50:25 UTC
I'm seeing this as well, I think.

Symptoms are: the actual html page downloads quickly (~0.5s), but the browser
stalls out for a while waiting on...something.

I've caught it happening on pages generated by avicenna and vincent
Comment 4 Antoine "hashar" Musso (WMF) 2005-01-11 17:18:11 UTC
Caching of css is probably fixed now. Please test again and reopen
this bug report if the problem still occur.

Note You need to log in before you can comment on or make changes to this bug.