Last modified: 2012-03-01 22:01:38 UTC
I've just upgraded to MediaWiki 1.17 and also updated my skin file to use ResourceLoader. But the problem is with ResourceLoader, that my site is loading from 8 secs to 2 mins… Before it took approximately 4-5 seconds. After I investigated the issue, I found out, that RL doesn't cache the generated minimized files, rather than it let a proxy to cache it for own purpose. It's very bad, because for a slow server (typical at hosting providers) every page generation takes a lot of time to generate to all users a dedicated JS and CSS file (which are mostly the same). For example phpBB stores its generated cache in the database. Wordpress with "W3 Total Cache" extension stores every minimized files on the file system after the first visitor had that generated (and even automatically stores that on a CDN). After I disabled the RL and removed it from my skin, the site loads again in 2 seconds. Here is a thread on it: http://lists.wikimedia.org/pipermail/mediawiki-l/2011-July/037638.html
(In reply to comment #0) > I've just upgraded to MediaWiki 1.17 and also updated my skin file to use > ResourceLoader. > But the problem is with ResourceLoader, that my site is loading from 8 secs to > 2 mins… Before it took approximately 4-5 seconds. > > After I investigated the issue, I found out, that RL doesn't cache the > generated minimized files, rather than it let a proxy to cache it for own > purpose. > It does cache it. If you have $wgCacheType = CACHE_DB; set (or CACHE_ACCEL if you use APC, or CACHE_MEMCACHED if you use memcached), it should cache it there. But if it's set to CACHE_NONE, it'll have nowhere to cache it.
szotsaki, what is wgCacheType set to in your LocalSettings?
This variable had no occurrence in my LocalSetttings.php, but I var_dump'ed it. PHP for this command `die( var_dump( $wgCacheType ));` replied: NULL.
I'm sorry, I meant $wgMainCacheType.
YSlow* reports that RL components are not gzipped: Not always but e.g. on http://www.mediawiki.org/wiki/Special:Watchlist Grade F on Compress components with gzip There are 11 plain text components that should be sent compressed http://bits.wikimedia.org/www.mediawiki.org/load.php?... http://bits.wikimedia.org/skins-1.17/monobook/main.css?... http://bits.wikimedia.org/skins-1.17/chick/main.css?... http://bits.wikimedia.org/w/extensions-1.17/LiquidThreads/lqt.css?... http://bits.wikimedia.org/w/extensions-1.17/FlaggedRevs/client/flaggedrevs.css?... http://bits.wikimedia.org/www.mediawiki.org/load.php?... http://bits.wikimedia.org/www.mediawiki.org/load.php?... http://bits.wikimedia.org/w/extensions-1.17/LiquidThreads/jquery/jquery.autogrow.js?... http://bits.wikimedia.org/w/extensions-1.17/LiquidThreads/lqt.js?... http://bits.wikimedia.org/w/extensions-1.17/LiquidThreads/js/lqt.toolbar.js?... http://bits.wikimedia.org/www.mediawiki.org/load.php?... * https://addons.mozilla.org/en-US/firefox/addon/yslow/
Created attachment 8817 [details] Firebug showing JS files Thank you for the tip; it was on CACHE_NONE. I set it to CACHE_DBA and now the .dba file is growing nicely. The situation is much better now, but unfortunately far from perfect. The specific site in my case is http://www.morrohun.hu/esl . As you can see in the attached picture, three JavaScript files load one after another, taking almost three seconds while blocking everything else. And while loading the HTML content there's no CSS file in the beginning (because it's still loading), that's why the browser shows a bare, white page for some seconds.
^^That's extreme. In your header only the shared and print.css is loaded? It misses the skin's main.css <link rel="stylesheet" href="/esl/load.php?debug=false&lang=hu&modules=mediawiki.legacy.commonPrint%2Cshared&only=styles&skin=morrohunv2&*" /> That's my header output for rel="stylesheet": <link rel="stylesheet" href="/wiki/load.php?debug=true&lang=en&modules=mediawiki.legacy.commonPrint&only=styles&skin=monobook&*" /> <link rel="stylesheet" href="/wiki/load.php?debug=true&lang=en&modules=mediawiki.legacy.shared&only=styles&skin=monobook&*" /> <link rel="stylesheet" href="/wiki/skins/monobook/main.css?404" media="screen" /> My problem is that I hide some elements via Common.css and dispaly them to certain users via user scripts. But with RL those are loaded at the bottom which makes some elements appear at the end of all DOM building.
(In reply to comment #5) > YSlow* reports that RL components are not gzipped: > > Not always but e.g. on http://www.mediawiki.org/wiki/Special:Watchlist > > Grade F on Compress components with gzip > > There are 11 plain text components that should be sent compressed > Using FF5, visiting [[mw:Special:Watchlist]] via the secure gateway, I do see Content-Encoding: gzip on the load.php requests. So this works for me.
as said, it works sometimes, sometimes not. try more pages please.
Yes, most of the skin files are in the extension (ext.MorroHun). Mostly, because I found little documentation about the migration (I swear, I read all of the articles). That's why MW has to load the normal load.php with CSS, which I think is by factory included, and also a version of mine which contains all of the necessary CSS rules. Documentation is really a big problem, I think, because I have no clue, how can I disable the deprecated wikibits.js and others; how can I reach my own JS functions (only related page I found is: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Talk:ResourceLoader/Using_with_extensions ). But this is an other issue; not related to this bug.
I think, I've found the major cause of this. There was a bug (Bug 262074) which caused the extension "load.php files" didn't get the proper &version parameter, thus somehow MediaWiki 1.17 always regenerated that. I applied the two fixes mentioned in the report and now, it appeals me much more :) Here are the two patches: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/80167 http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81689 Btw. according to the roadmap, 1.18 will be here in a half month, and that will contain the fix. Could you please test it?
(In reply to comment #11) > Here are the two patches: > http://www.mediawiki.org/wiki/Special:Code/MediaWiki/80167 > http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81689 > Yeah, I remember those. They were merged to 1.17wmf1, but I guess they were never merged to 1.17 then. 1.18 should be out relatively soon, yeah.
> Yeah, I remember those. They were merged to 1.17wmf1, but I guess they were > never merged to 1.17 then. > > 1.18 should be out relatively soon, yeah. Still, it would be great if we backported them to 1.17 cause we probably need a bugfix release already.
