Last modified: 2010-05-15 15:28:21 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 812 - Performance issues with 1.3.6 and 1.3.7
Performance issues with 1.3.6 and 1.3.7
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.3.x
PC Linux
: Normal critical (vote)
: ---
Assigned To: Nobody - You can work on this!
http://wiki.felix-schwarz.info
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-31 18:33 UTC by Felix Schwarz
Modified: 2010-05-15 15:28 UTC (History)
0 users

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


Attachments

Description Felix Schwarz 2004-10-31 18:33:44 UTC
Since upgrading from 1.3.5 I experience severe performance issues:
One part of the problem are multiple requests within the page load. 

For example I'm seeing request as this 21 times:
213.20.141.149 - - [31/Oct/2004:19:19:35 +0100] "GET
/?title=Benutzer:Felix/monobook.js&action=raw&ctype=text%2Fjavascript&smaxage=18000&maxage=18000&gen=&oldid=0
HTTP/1.1" 302 26 "http://wiki.felix-schwarz.info/Hauptseite" "Mozilla/5.0
(Windows; U; Windows NT 5.0; de-AT; rv:1.7) Gecko/20040616"

Another admin sees this problem on his server, too.
Comment 1 Brion Vibber 2004-10-31 23:59:14 UTC
Well, this link shows an example of your problem:

<script src="?title=-&amp;action=raw&amp;gen=js" type="text/
javascript"></script>

Have you set $wgScript to "" manually? This is fairly certain to fail in 
horrible ways. Try setting it to an actual location.

If that's not what you did, can you please list what you've done?
Comment 2 Felix Schwarz 2004-11-01 09:13:41 UTC
yes, actually I set $wgScript to "" because I use a completely separate
subdomain for my mediawiki installation so I thought that $wgScript="" would be
the correct setting. What is configuration for that?

The same setting is okay with 1.3.5. Why was that changed?

If this setting is so horribly wrong: Why isn't there a warning in
LocalSettings.php?

thanks for your help.
Comment 3 Brion Vibber 2004-11-01 09:38:30 UTC
I think what you want to do is to set $wgArticlePath, which controls the URL path used for 
plain user-visible page views, like this:

  $wgArticlePath = "/$1";

You should never set $wgScript to something that is not, in fact, the URL path to the script. If 
it doesn't start with "/" and end in "index.php", you are probably setting it wrong unless you 
have a very clear reason otherwise.

Setting it to "" is guaranteed to fail because this produces a relative path to whatever the 
originating page was, and will therefore never produce a correct, canonical path -- thus 
sending you into an infinite loop as the wiki tries to redirect to the canonical URL.

1.3.7 is more aggressive about uses of the 'raw' page loading mode because it's possible to 
abuse  it in a way that exposes a security hole in Internet Explorer for Windows, which could 
be used by a malicious person to attack your users, possibly compromising their wiki 
accounts. The workaround is to ensure that raw accesses are done using the canonical script 
URL -- which is impossible when you have incorrectly set $wgScript in this way. Raw loading 
is used for customizable global and per-user style sheets and JavaScript, hence the failure 
when it's impossible to use this mode.

Among this and other problems it will also produce many staggeringly incorrect links if you 
ever visit a page title with a slash in the name (as the browser will try to resolve it as a 
relative path as though there were a subdirectory). This would have failed equally in 1.3.5, 
though you might not have happened to come across it.
Comment 4 Felix Schwarz 2004-11-01 17:26:31 UTC
okay, with the following settings performance goes back to normal:

$wgScriptPath       = "/";
$wgArticlePath      = $wgScript."$1";
$wgStylePath        = "/stylesheets";

Thanks for your help.

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


Navigation
Links