Hi,
Mediawiki's performance has improved substantially over the versions. and 1.9 seems the snappiest yet. When I upgraded I found I had some slow stuff being loaded in addition to MW. Using Firebug beta (v cool BTW) I noticed something odd. The index.php for the page loads blindingly fast, but the following:
/index.php?title=-&action=raw&smaxage=0&gen=jshttp://www.exscien.com/internal/index.php?title=-&action=raw&smaxage=0&gen=js /index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000http://www.exscien.com/internal/index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000 /index.php?title=User:Alexp/monobook.css&action=raw&ctype=text/csshttp://www.exscien.com/internal/index.php?title=User:Alexp/monobook.css&action=raw&ctype=text/css /index.php?title=-&action=raw&gen=css&maxage=18000&smaxage=0&ts=20070129214411http://www.exscien.com/internal/index.php?title=-&action=raw&gen=css&maxage=18000&smaxage=0&ts=20070129214411
... seem to run very slowly (one was taking 2 seconds and each take over .5secs, on a page that took 16ms to render). What can be done to speed them? As far as I can see they are just simple js direct from the DB. Am I missing something or is there a performance hole there?
Best regards,
Alex
Alex Powell wrote:
Hi,
Mediawiki's performance has improved substantially over the versions. and 1.9 seems the snappiest yet. When I upgraded I found I had some slow stuff being loaded in addition to MW. Using Firebug beta (v cool BTW) I noticed something odd. The index.php for the page loads blindingly fast, but the following:
/index.php?title=-&action=raw&smaxage=0&gen=jshttp://www.exscien.com/internal/index.php?title=-&action=raw&smaxage=0&gen=js /index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000http://www.exscien.com/internal/index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000 /index.php?title=User:Alexp/monobook.css&action=raw&ctype=text/csshttp://www.exscien.com/internal/index.php?title=User:Alexp/monobook.css&action=raw&ctype=text/css /index.php?title=-&action=raw&gen=css&maxage=18000&smaxage=0&ts=20070129214411http://www.exscien.com/internal/index.php?title=-&action=raw&gen=css&maxage=18000&smaxage=0&ts=20070129214411
... seem to run very slowly (one was taking 2 seconds and each take over .5secs, on a page that took 16ms to render). What can be done to speed them? As far as I can see they are just simple js direct from the DB. Am I missing something or is there a performance hole there?
Get a better computer. Seriously, I suspect firebug is timing the firefox rendering time (for css) and execution time (for js). Try using wget, it will be faster (or disable javascript).
Hi,
No not that. I have a 2 GHz core duo at both ends, runnning no AV software (!), or anything else. The machine is "sufficient". Wiki pages without those two (stripped them out) take 180millis by Firebug.
Testing against the wikipedia, it took 200millis on first hit, and then 16 millis on subsiqent. I suspect the squid caches had it in their mits at that point. The page is pulled with some unusual parameters, I was wondering if that was pushing the code down an unusual path...
Alex
On 1/29/07, Ashar Voultoiz hashar@altern.org wrote:
Alex Powell wrote:
Hi,
Mediawiki's performance has improved substantially over the versions.
and
1.9 seems the snappiest yet. When I upgraded I found I had some slow
stuff
being loaded in addition to MW. Using Firebug beta (v cool BTW) I
noticed
something odd. The index.php for the page loads blindingly fast, but the following:
/index.php?title=-&action=raw&smaxage=0&gen=js<
http://www.exscien.com/internal/index.php?title=-&action=raw&smaxage...
/index.php?title=MediaWiki:
Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000< http://www.exscien.com/internal/index.php?title=MediaWiki:Common.css&use...
/index.php?title=User:Alexp/monobook.css&action=raw&ctype=text/css<
http://www.exscien.com/internal/index.php?title=User:Alexp/monobook.css&...
/index.php?title=-&action=raw&gen=css&maxage=18000&smaxage=0&ts=20070129214411< http://www.exscien.com/internal/index.php?title=-&action=raw&gen=css...
... seem to run very slowly (one was taking 2 seconds and each take over .5secs, on a page that took 16ms to render). What can be done to speed
them?
As far as I can see they are just simple js direct from the DB. Am I
missing
something or is there a performance hole there?
Get a better computer. Seriously, I suspect firebug is timing the firefox rendering time (for css) and execution time (for js). Try using wget, it will be faster (or disable javascript).
-- Ashar Voultoiz - WP++++ http://en.wikipedia.org/wiki/User:Hashar http://www.livejournal.com/community/wikitech/ IM: hashar@jabber.org ICQ: 15325080
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Well I'm not running squid, and here's the test script I'm running and the timing results I'm seeing on my local test wiki:
-------------------------------------- root@bling:~/tmp# cat test.sh #!/bin/bash time wget --output-document=index-1.js "http://192.168.0.64/wiki/index.php?title=-&action=raw&smaxage=0&..." time wget --output-document=index-2.css "http://192.168.0.64/wiki/index.php?title=MediaWiki:Common.css&usemsgcach..." time wget --output-document=index-3.css "http://192.168.0.64/wiki/index.php?title=-&action=raw&gen=css&ma..." root@bling:~/tmp# root@bling:~/tmp# ./test.sh --12:40:44-- http://192.168.0.64/wiki/index.php?title=-&action=raw&smaxage=0&... => `index-1.js' Connecting to 192.168.0.64:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3,788 (3.7K) [text/javascript] 12:40:45 (212.50 MB/s) - `index-1.js' saved [3788/3788]
real 0m0.237s user 0m0.004s sys 0m0.000s --12:40:45-- http://192.168.0.64/wiki/index.php?title=MediaWiki:Common.css&usemsgcach... => `index-2.css' Connecting to 192.168.0.64:80... connected. HTTP request sent, awaiting response... 200 OK Length: 28 [text/css] 12:40:45 (2.97 MB/s) - `index-2.css' saved [28/28]
real 0m0.198s user 0m0.008s sys 0m0.004s --12:40:45-- http://192.168.0.64/wiki/index.php?title=-&action=raw&gen=css&ma... => `index-3.css' Connecting to 192.168.0.64:80... connected. HTTP request sent, awaiting response... 200 OK Length: 75 [text/css] 12:40:45 (8.94 MB/s) - `index-3.css' saved [75/75]
real 0m0.228s user 0m0.004s sys 0m0.004s root@bling:~/tmp# --------------------------------------
I.e. total time = 0.237 + 0.198 + 0.228 = 0.663 seconds.
I take it for the Firebug timing values, that you're going Tools -> Firebug -> Open Firebug -> click on "Net" -> make sure "All" is selected -> read the timing values for the various scripts?
If so, my times are 10 ms, 150 ms, and 160 ms, respectively for the above 3 files.
However, ajaxwatch.js for me shows as taking 351 ms, which seems rather long.
However, when I try to fetch ajaxwatch on the command line, I get a very different result:
-------------------------------------- root@bling:~/tmp# time wget --output-document=ajaxwatch.js "http://192.168.0.64/wiki/skins/common/ajaxwatch.js" --12:56:20-- http://192.168.0.64/wiki/skins/common/ajaxwatch.js => `ajaxwatch.js' Connecting to 192.168.0.64:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3,916 (3.8K) [application/x-javascript] 12:56:20 (219.68 MB/s) - `ajaxwatch.js' saved [3916/3916]
real 0m0.008s user 0m0.004s sys 0m0.004s root@bling:~/tmp# --------------------------------------
I.e. only 2.3% of the time that Firebug reports. A 43-times difference like this is an enormous difference - the difference between blazingly fast, and pig slow.
Refreshing the page shows that Firebug thinks Monobook.css took 791 ms; however the command line repeatably shows values between 0.197s and 0.210s.
I think there may be a few problems or explanations here: * The Firebug times I suspect include the time that Firefox spends client-side processing the CSS or JS (i.e. not just the time to fetch from the network). I.e. image rendering times, JavaScript execution times, page layout times, etc. If that's correct, what would be useful would be is if the Firebug times separated out network fetch times, and local client processing times, for each item. * The Firebug times do not seem to be as repeatable as one would like for systematic testing (e.g. total page display times varied between 2.5 seconds and 3.5 seconds). Part of this may be the Observer effect (i.e. Firebug is embedded in Firefox, and the act of observing Firefox and continuously reporting on its rendering times probably makes Firefox slower, and/or introduces variability). * I have gzip compression turned on, and probably Firefox uses this, whereas wget probably does not.
Basically, I'm unsure what to make of the Firebug times, except to say that the times Firebug reports do not immediately appear to correlate well with the time taken to retrieve the raw content from the network.
Also, on a related note, for requesting ajaxwatch.js, we should probably be tacking on the "?52" version string thing somewhere (which from the Firebug output it looks like we're not currently doing).
All the best, Nick.
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org]On Behalf Of Alex Powell Sent: Wednesday, 31 January 2007 2:18 AM To: Wikimedia developers Subject: Re: [Wikitech-l] Performance of loading custom style sheets
Hi,
No not that. I have a 2 GHz core duo at both ends, runnning no AV software (!), or anything else. The machine is "sufficient". Wiki pages without those two (stripped them out) take 180millis by Firebug.
Testing against the wikipedia, it took 200millis on first hit, and then 16 millis on subsiqent. I suspect the squid caches had it in their mits at that point. The page is pulled with some unusual parameters, I was wondering if that was pushing the code down an unusual path...
Alex
On 1/29/07, Ashar Voultoiz hashar@altern.org wrote:
Alex Powell wrote:
Hi,
Mediawiki's performance has improved substantially over the versions.
and
1.9 seems the snappiest yet. When I upgraded I found I had some slow
stuff
being loaded in addition to MW. Using Firebug beta (v cool BTW) I
noticed
something odd. The index.php for the page loads blindingly fast, but the following:
/index.php?title=-&action=raw&smaxage=0&gen=js<
http://www.exscien.com/internal/index.php?title=-&action=raw&smaxage...
/index.php?title=MediaWiki:
Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000< http://www.exscien.com/internal/index.php?title=MediaWiki:Common.css&use...
/index.php?title=User:Alexp/monobook.css&action=raw&ctype=text/css<
http://www.exscien.com/internal/index.php?title=User:Alexp/monobook.css&...
/index.php?title=-&action=raw&gen=css&maxage=18000&smaxage=0&ts=20070129214411< http://www.exscien.com/internal/index.php?title=-&action=raw&gen=css...
... seem to run very slowly (one was taking 2 seconds and each take over .5secs, on a page that took 16ms to render). What can be done to speed
them?
As far as I can see they are just simple js direct from the DB. Am I
missing
something or is there a performance hole there?
Get a better computer. Seriously, I suspect firebug is timing the firefox rendering time (for css) and execution time (for js). Try using wget, it will be faster (or disable javascript).
-- Ashar Voultoiz - WP++++ http://en.wikipedia.org/wiki/User:Hashar http://www.livejournal.com/community/wikitech/ IM: hashar@jabber.org ICQ: 15325080
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
I agree that Firebug times are erratic. I have put much of this down to normal network lag/server lag. I am running a windows server running PHP using the DLL version, and I think it sometimes gets locked during the request. I am looking into getting FastCGI working to see if it is more consistant but have never been fond of recompiling and XAMPP doesn't seem to like to load any of the versions out there.
Don't suppose anyone has any experience of FastCGI under windows? Is it worth it over the DLL? Does it make the server more stable? I'm running PHP 5.2.0 with APC at the mo.
If the timings of loading the user style sheet is wrong, then fine. Might be worth hacking in an optional timing into output=js as a JS comment, to prove it once and for all.
On 1/31/07, Nick Jenkins nickpj@gmail.com wrote:
Well I'm not running squid, and here's the test script I'm running and the timing results I'm seeing on my local test wiki:
root@bling:~/tmp# cat test.sh #!/bin/bash time wget --output-document=index-1.js "http://192.168.0.64/wiki/index.php?title=-&action=raw&smaxage=0&... " time wget --output-document=index-2.css "http://192.168.0.64/wiki/index.php?title=MediaWiki:Common.css&usemsgcach... " time wget --output-document=index-3.css "http://192.168.0.64/wiki/index.php?title=-&action=raw&gen=css&ma... " root@bling:~/tmp# root@bling:~/tmp# ./test.sh --12:40:44-- http://192.168.0.64/wiki/index.php?title=-&action=raw&smaxage=0&... => `index-1.js' Connecting to 192.168.0.64:80 http://192.168.0.64/... connected. HTTP request sent, awaiting response... 200 OK Length: 3,788 (3.7K) [text/javascript] 12:40:45 (212.50 MB/s) - `index-1.js' saved [3788/3788]
real 0m0.237s user 0m0.004s sys 0m0.000s --12:40:45-- http://192.168.0.64/wiki/index.php?title=MediaWiki:Common.css&usemsgcach... => `index-2.css' Connecting to 192.168.0.64:80 http://192.168.0.64/... connected. HTTP request sent, awaiting response... 200 OK Length: 28 [text/css] 12:40:45 (2.97 MB/s) - `index-2.css' saved [28/28]
real 0m0.198s user 0m0.008s sys 0m0.004s --12:40:45-- http://192.168.0.64/wiki/index.php?title=-&action=raw&gen=css&ma...
=> `index-3.css'Connecting to 192.168.0.64:80 http://192.168.0.64/... connected. HTTP request sent, awaiting response... 200 OK Length: 75 [text/css] 12:40:45 (8.94 MB/s) - `index- 3.css' saved [75/75]
real 0m0.228s user 0m0.004s sys 0m0.004s root@bling:~/tmp#
I.e. total time = 0.237 + 0.198 + 0.228 = 0.663 seconds.
I take it for the Firebug timing values, that you're going Tools -> Firebug -> Open Firebug -> click on "Net" -> make sure "All" is selected -> read the timing values for the various scripts?
If so, my times are 10 ms, 150 ms, and 160 ms, respectively for the above 3 files.
However, ajaxwatch.js for me shows as taking 351 ms, which seems rather long.
However, when I try to fetch ajaxwatch on the command line, I get a very different result:
root@bling:~/tmp# time wget --output-document=ajaxwatch.js "http://192.168.0.64/wiki/skins/common/ajaxwatch.js " --12:56:20-- http://192.168.0.64/wiki/skins/common/ajaxwatch.js => `ajaxwatch.js' Connecting to 192.168.0.64:80 http://192.168.0.64/... connected. HTTP request sent, awaiting response... 200 OK Length: 3,916 (3.8K) [application/x-javascript] 12:56:20 (219.68 MB/s) - `ajaxwatch.js' saved [3916/3916]
real 0m0.008s user 0m0.004s sys 0m0.004s root@bling:~/tmp#
I.e. only 2.3% of the time that Firebug reports. A 43-times difference like this is an enormous difference - the difference between blazingly fast, and pig slow.
Refreshing the page shows that Firebug thinks Monobook.css took 791 ms; however the command line repeatably shows values between 0.197s and 0.210s.
I think there may be a few problems or explanations here:
- The Firebug times I suspect include the time that Firefox spends
client-side processing the CSS or JS (i.e. not just the time to fetch from the network). I.e. image rendering times, JavaScript execution times, page layout times, etc. If that's correct, what would be useful would be is if the Firebug times separated out network fetch times, and local client processing times, for each item.
- The Firebug times do not seem to be as repeatable as one would like for
systematic testing ( e.g. total page display times varied between 2.5 seconds and 3.5 seconds). Part of this may be the Observer effect (i.e. Firebug is embedded in Firefox, and the act of observing Firefox and continuously reporting on its rendering times probably makes Firefox slower, and/or introduces variability).
- I have gzip compression turned on, and probably Firefox uses this,
whereas wget probably does not.
Basically, I'm unsure what to make of the Firebug times, except to say that the times Firebug reports do not immediately appear to correlate well with the time taken to retrieve the raw content from the network.
Also, on a related note, for requesting ajaxwatch.js, we should probably be tacking on the "?52" version string thing somewhere (which from the Firebug output it looks like we're not currently doing).
All the best, Nick.
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org]On Behalf Of Alex Powell Sent: Wednesday, 31 January 2007 2:18 AM To: Wikimedia developers Subject: Re: [Wikitech-l] Performance of loading custom style sheets
Hi,
No not that. I have a 2 GHz core duo at both ends, runnning no AV
software
(!), or anything else. The machine is "sufficient". Wiki pages without
those
two (stripped them out) take 180millis by Firebug.
Testing against the wikipedia, it took 200millis on first hit, and then
16
millis on subsiqent. I suspect the squid caches had it in their mits at
that
point. The page is pulled with some unusual parameters, I was wondering
if
that was pushing the code down an unusual path...
Alex
On 1/29/07, Ashar Voultoiz hashar@altern.org wrote:
Alex Powell wrote:
Hi,
Mediawiki's performance has improved substantially over the
versions.
and
1.9 seems the snappiest yet. When I upgraded I found I had some slow
stuff
being loaded in addition to MW. Using Firebug beta (v cool BTW) I
noticed
something odd. The index.php for the page loads blindingly fast, but
the
following:
/index.php?title=-&action=raw&smaxage=0&gen=js<
http://www.exscien.com/internal/index.php?title=-&action=raw&smaxage...
/index.php?title=MediaWiki:
Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000<
http://www.exscien.com/internal/index.php?title=MediaWiki:Common.css&use...
/index.php?title=User:Alexp/monobook.css&action=raw&ctype=text/css<
http://www.exscien.com/internal/index.php?title=User:Alexp/monobook.css&...
/index.php?title=-&action=raw&gen=css&maxage=18000&smaxage=0&ts=20070129214411<
http://www.exscien.com/internal/index.php?title=-&action=raw&gen=css...
... seem to run very slowly (one was taking 2 seconds and each take
over
.5secs, on a page that took 16ms to render). What can be done to
speed
them?
As far as I can see they are just simple js direct from the DB. Am I
missing
something or is there a performance hole there?
Get a better computer. Seriously, I suspect firebug is timing the firefox rendering time (for css) and execution time (for js). Try
using
wget, it will be faster (or disable javascript).
-- Ashar Voultoiz - WP++++ http://en.wikipedia.org/wiki/User:Hashar http://www.livejournal.com/community/wikitech/ IM: hashar@jabber.org ICQ: 15325080
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Alex Powell wrote:
I agree that Firebug times are erratic. I have put much of this down to normal network lag/server lag. I am running a windows server running PHP using the DLL version, and I think it sometimes gets locked during the request. I am looking into getting FastCGI working to see if it is more consistant but have never been fond of recompiling and XAMPP doesn't seem to like to load any of the versions out there.
Don't suppose anyone has any experience of FastCGI under windows? Is it worth it over the DLL? Does it make the server more stable? I'm running PHP 5.2.0 with APC at the mo.
[...]
I don't have experience with that, but I use WAMP Server: http://www.wampserver.com/en/
It's Apache, MySQL and PHP in one package for windows. Very useful.
Boris
wikitech-l@lists.wikimedia.org