On Tue, Jun 24, 2008 at 4:44 PM, Travis (wikiHow) <travis(a)wikihow.com> wrote:
Hi,
I'm still working on upgrading us to 1.12 and after upgrading the
extensions, I'm noticing that the 1.12 upgrade still takes a lot longer to
render a page. For ( $elapsed = $now - $wgRequestTime;) for 1.9, I usually
see on average about 0.15 seconds to serve a page, while 1.12 I'm seeing
more like 0.50 seconds, with both installations running on the same server
and connected to the same DB server, etc.
Here are some of the functions I'm seeing take awhile in the profiler.
462.884 MediaWiki::initialize
395.097 MediaWiki::performAction
328.284 Article::view
233.001 Parser::parse
232.899 Parser::parse-Article::outputWikiText
134.212 Parser::internalParse
103.388 Parser::replaceVariables
252.385 MediaWiki::finalCleanup
251.857 OutputPage::output
251.402 Output-skin
251.332 SkinTemplate::outputPage
209.752 SkinTemplate::outputPage-execute
855.008 -total
The full profile is here:
http://69.20.102.10/x/profile_deep.txt
Any ideas? I've tried drilling down into finding out why some of these are
taking a long time. replaceInternalLinks seems to take a long time sometimes
because the LocalFile::loadFromDB DB select statement sometimes takes over
50ms, but it looks like our indices in the image table are fine.
mysql> check table image;
+------------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+------------------+-------+----------+----------+
| wikidb_112.image | check | status | OK |
+------------------+-------+----------+----------+
1 row in set (1.73 sec)
Thanks,
Travis
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
A fair bit of setup time could be saved if Kaltura lazy-loaded their
extension messages
(registering them with $wgExtensionMessagesFiles) and then loading
them on-demand
with wfLoadExtensionMessages(). Every hit to the website is forcing
Kaltura to load
their messages via the KalturaInstall class' constructor. Their code
isn't the easiest to
follow, so I can't really suggest a fix here (plus, they don't host it
in SVN, it's over on
Sourceforge).
-Chad