What the wiki looks like

The only page that looks much different from Wikipedia or any other MediaWiki-based wiki is the Special:Version page. I've included a screen-grab of that so you can see how my version is different from the mainstream MediaWiki engine. In particular, notice IIS instead of Apache, the ADOdb library and SQL Server instead of the MySQL library and MySQL, and a slightly different version of PHP (this is the version from Zend Core)


More speed tests

Having been pleased with the effects of the Zend Optimizer, I began to wonder what the effects would be of running the entire MediaWiki software on the commercial Zend Core engine. Here are some samples (all times in seconds):
PagePHP No optimization PHPw/Optimizer Zend Core Wikipedia
2003 invasion of Baghdad3.323.200.690.34
2003 Invasion of Iraq20.765.456.664.09
Air Force Special Operations Command1.160.630.480.21
World Geodetic System1.321.751.300.36
United States Department of Justice2.030.940.770.54
United States Air Force6.477.242.171.17
The Sunshine Boys1.930.820.620.37
Ruby on Rails1.7515.880.650.25
Lee Meredith0.850.530.370.18
Arnold Schwarzenegger1573.914.03
Note that these are the times reported by PHP (as can be seen with the view source command on the resulting web page). Also note that the times vary significantly depending on what the server may be doing at the time. The times reported for my server are for uncached results, whereas the times reported for Wikipedia are presumably usually for cached results -- except for Arnold, it looks like I found him out of the cache this time around!


Version 1.10 on SQL Server

MediaWiki 1.10 is out. That's my cue to start trying to get my changes integrated into the shared source code. I've started on that with a Bugzilla, Bug # 9767 I pretty much have 1.10 all working, except the thumbnail functionality stopped working. In my configuration, ImageMagick 6.3.2-5 is used to generate the thumbnails. Now, instead of thumbnails, I get "Error creating thumbnail: The input line is too long". The first part of this message, up to the colon, is generated by the PHP code. The second part, however, appears to come from ImageMagick itself. In my modified MediaWiki version 1.9.3, this had been working -- so I need to figure out what's changed. (... a little time goes by ...) OK, It's not ImageMagick's fault. The problem had to do with the documented (http://news.php.net/php.internals/21796) flaw with PHP's invocation of cmd.exe. My implementation of the wfShellExec function in GlobalFunctions.php now contains this:
   } elseif (php_uname( 's' ) == 'Windows NT' ) {
      # This is a hack to work around PHP's flawed invocation of cmd.exe
      # http://news.php.net/php.internals/21796
      $cmd = 'cmd /C ' . '"' . str_replace( '/', '\\', $cmd) . '"';
   wfDebug ( "wfShellExec: $cmd\n" );

   $output = array();
   $retval = 1; // error by default?
   exec( $cmd, $output, $retval ); // returns the last line of output.
   return implode( "\n", $output);
Note that this differs in two ways from the distributed version of GlobalFunctions.php:
  1. Prefixes the command with "cmd /C"
  2. Replaces all occurrences of slash with backslash
I did the first, as I remember, to get Batik to work (for processing SVGs), which is driven by a batch file. I did the second to get some consistency in the direction the slashes are facing. The MediaWiki code is a little bit unclear when it decides to stick slashes into strings that represent filenames, and sometimes uses pieces of a URL (forward slash) to append subdirectory names to existing directories (backward slash). All I do is format the result as though it's a filename (which it will always be in this situation, since we're trying to execute something). Naturally, there will be a problem if there ever arises a situation in which the slashes are being used for something else, but I haven't seen this happen. Presumably they would show up uuencoded if they were being used (say) as part of an argument to a command.

Making it fast

Until today, I have been reasonably disappointed at the speed at which the pages in my wiki have been coming up. Wikipedia uses lots of stunts which aren't really open to me, like using Squid together with lots & lots of slaved servers. Right now, I'm just running on a two-processor (2 x 3GHz Pentium) box with 2GB of memory. SQL Server, IIS, etc. are all running locally. In this configuration, pages were taking anywhere from 2 to 10 times as long to display as the corresponding pages from Wikipedia. The fix is in. I suspected that a PHP accelerator would work, and it does -- beyond my expectations. All of a sudden, this wiki is snappy! The trick is getting a PHP accelerator that works in our configuration (Windows 2003 SE, IIS 6, PHP 5, etc.) The one that does it is Zend Optimizer. It's a free download. Thanks, Zend. If you're running any PHP on IIS, give it a try. I think you'll be impressed. Here are some example timings for my wiki, along with times from wikipedia.org:
Page titleTime before optimizerTime after optimizerWikipedia time
Philippines25 seconds5 seconds4 seconds
Arnold Schwarzenegger15 seconds7 seconds5 seconds