Last modified: 2014-07-16 12:18:43 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 40260 - Long delay in passing a request to long pages in Arabic Wikipedia
Long delay in passing a request to long pages in Arabic Wikipedia
Status: NEW
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
: performance
Depends on:
  Show dependency treegraph
Reported: 2012-09-15 02:43 UTC by Antime
Modified: 2014-07-16 12:18 UTC (History)
6 users (show)

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


Description Antime 2012-09-15 02:43:51 UTC
Hello, in Arabic wikipedia, many users report technical difficulties when they try to access the main page. some user have reported a very long delay (about 1-2 minutes) before they can load the main page. I was suspecting a server name indication since the secure server produced an error about the main page was not exit! 
They experience the same issue after purge/bypass main page,s cache.
The errors occur per requesting the main page within the mediawiki interface using the main page's link, or by typing the address directly.
Here is some error they have reported:

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /wikipedia/ar/wiki/الصÙحة_الرئيسية.
Reason: Error reading from remote server
Apache/2.2.14 (Ubuntu) Server at Port 443
A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See:
  Query: UPDATE `user` SET user_touched = '20120911172013' WHERE user_id = '138585' AND (user_touched < '20120911172013')
  Function: User::invalidateCache
while other pages can be modify/read naturally, a request to the main page made by a user who saved the main page,s path in his bookmark produce this error:

Request: GET, from via cp1004.eqiad.wmnet (squid/2.7.STABLE9) to (
Error: ERR_READ_TIMEOUT, errno [No Error] at Fri, 14 Sep 2012 10:58:32 GMT

I,d like some one to investigate the issue and give me a recommendation and feedback, best regards.
Comment 1 Zack 2012-11-13 01:40:49 UTC
Plus certain long pages can't be edited unless user has logged off, e.g.اليمن
Comment 2 Andre Klapper 2012-11-13 01:53:50 UTC lots for me in under four seconds (Firefox 16.0.2), but takes more than 10 seconds too load, very likely because it uses lots of templates (which would make this a duplicate of bug 19262)

Also see
Comment 3 Zack 2012-11-17 17:57:41 UTC
(In reply to comment #2)
> takes more than 10
> seconds too load, very likely because it uses lots of templates (which would
> make this a duplicate of bug 19262)
Comment 4 Sam Reed (reedy) 2013-05-14 17:12:21 UTC
NewPP limit report
Preprocessor visited node count: 40470/1000000
Preprocessor generated node count: 108070/1500000
Post‐expand include size: 825656/2048000 bytes
Template argument size: 579967/2048000 bytes
Highest expansion depth: 25/40
Expensive parser function count: 4/500

^ It doesn't look to be that bad..

But it takes over a minute for the html text

Removing the URL from the top as it upsets bugzilla
Comment 5 Andre Klapper 2014-07-16 12:18:43 UTC
Antime / Zack: Is this still a problem for the main page? Loading time here was acceptable (less than 8 seconds) with a clean browser cache.

I also tried the Yemen article on three times, and the 3.8MB for that article taking always between 27 and 29 seconds in Firefox 30 with the "Network" tab of the "Developer tools" (but please do note that ?forceprofile=true makes it way slower!).

Top of profile output in its HTML source looks like this:

100.89% 1.450530      2 - WebStart.php-conf
100.77% 1.448705      2 - CommonSettings.php
100.00% 1.437702      1 - -total
 95.20% 1.368729      1 - MediaWiki::main
 75.44% 1.084556      1 - OutputPage::output
 74.38% 1.069343      1 - Output-skin
 74.33% 1.068663      1 - SkinTemplate::outputPage
 67.01% 0.963423      1 - SkinTemplate::prepareQuickTemplate
 55.46% 0.797374      1 - SkinTemplate::prepareQuickTemplate-stuff4
 22.52% 0.323773    188 - hook: LanguageGetTranslatedLanguageNames
 21.40% 0.307620    188 - LanguageNames::coreHook
 18.26% 0.262488      1 - MediaWiki::performRequest
 15.89% 0.228470      1 - MediaWiki::performAction
 15.72% 0.226043      1 - Article::view
 10.74% 0.154429    576 - MessageCache::get

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