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

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3230, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1230 - GET /wiki/common/common.css take 168 seconds
GET /wiki/common/common.css take 168 seconds
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  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: ---


Attachments

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 http://fr.wikipedia.org/wiki/Nuage_mol%C3%A9culaire and
capture the frame via ethereal.

Results:
* 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 http://fr.wikipedia.org/wiki/Phé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 wikipedia.org
             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 wikipedia.org
             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 wikipedia.org
             Connection: keep-alive
30.960891 <- (last packet)
30.972050 -> GET
/w/index.php?title=Utilisateur:Looxix/standard.js&action=raw&ctype=text/javascript
HTTP/1.1
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 wikipedia.org
             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 wikipedia.org
             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.


Navigation
Links