On Thu, Jun 26, 2008 at 3:45 PM, Travis (wikiHow) travis@wikihow.com wrote:
The 1.9 and 1.12 installs are running on the same machine, and are not receiving any traffic other than my testing. 1.9 is pointing to a production DB instance, both are pointing to the same MySQL server, but I changed the wgProxyKey for both installs so they don't hit the live memcached, could 1.9 be getting some cached data from the production DB to make it perform better?
Yes, definitely! It will use the OS cache for the file blocks and the MyISAM key buffer for the key blocks. It will be working with hot data, so it will certainly be much faster. A typical view on your 1.9 instance might require no actual disk reads at all, while your 1.12 install could require many. A key buffer hit wouldn't even require a system call. This could easily account for a fourfold difference or more -- in principle, even a thousand-fold difference, although you aren't seeing that here (production cache might not be totally hot, dev cache might not be totally cold).
You could try hitting the 1.12 install with artificial traffic to populate the caches, but it's still not necessarily going to behave quite the same. For performance benchmarking you really want exactly the same load patterns on everything you're testing. How far you want to go in achieving this is up to you. At a minimum I'd copy the 1.9 DB twice to two separate dev databases, and upgrade one of them. You could then do benchmarking with ab or a similar tool.
I'll take a look into the extra queries, they could be coming from our customizations and extensions.
Two significant things that come to mind in the core software config: one, if you're running a large number of interwikis, you need special configuration for that to avoid a ton of DB traffic. Two, you should set $wgJobRunRate = 0 and have the job queue run using maintenance/runJobs.php in cron, not on each page view.
This query occassionally takes a long time to execute, not sure why:
SELECT /* Parser::replaceLinkHolders */ page_id, page_namespace, page_title, page_is_redirect FROM `page` WHERE (page_namespace=0 AND page_title IN('Study-Better', 'Have-Fun-While-Studying', 'Socialize,-Be-Funny-and-Make-Friends', 'Create-Good-Study-Habits-for-Exams', 'Get-Good-Grades', 'Ace-Your-Next-Test', 'Get-Straight-A's', 'Upgrade-Your-Life-As-a-Teenager'))
It's almost certainly a bogus statistic. It could just reflect a long time waiting for a lock or something.
No idea! Is it possible because we originally created this DB with a MW 1.3 install, that not all the tables have been converted? It looks like our `archive` table is MyISAM, but in the new MW installs, it's InnoDB. Should we switch them all over to be Inno?
I'd imagine that would be a good idea, yes. Make sure you reconfigure MySQL, though! Standard settings are totally unacceptable for heavy InnoDB use. You'll want to set key_buffer_size smaller and increase innodb_buffer_pool_size to most of your database server's available memory (if no serious MyISAM apps are running on the DB server -- and anyway temporary tables are always MyISAM, so don't set key_buffer_size too small!). This is a good article to read:
http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimizati...
Cool, I didn't know this existed. I'll use this next time.
It's covered in the manual: