On Thu, Jun 26, 2008 at 3:45 PM, Travis (wikiHow) <travis(a)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-optimizat…
Cool, I didn't know this existed. I'll use
this next time.
It's covered in the manual:
http://www.mediawiki.org/wiki/Manual:Upgrading_to_1.12