I recently added complete unit test coverage to my simpletest module, both for 6.x and 7.0 UNSTABLE 7.
The same set of tests (currently in CVS), on the same module (except for the minor changes needed for the port), on the same server, takes about three times as long on D7 than on D6. I haven't noticed similar speed differences for anything else on D7 vs D6.
D7 version: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/taxonews/ta...
D6 version: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/taxonews/ta...
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 513592-registry-speedup-md5.patch | 6.73 KB | damien tournoud |
Comments
Comment #1
fgmeerrrrr... I mean my "taxonews" module, not "simpletest", of course.
Obviously, this can also be an error in my tests, but I somehow doubt it because they are not very complicated.
Comment #2
chx commentedCurious. Have you tried running xdebug and kcachegrind to see what's going on? Is db_insert this much slower? Can be... but still curious.
Comment #3
damien tournoud commentedWell, the registry can explain a big part of that. Even if we do preload the registry, we still have to traverse the hierarchy of files and compute md5() hashes of them. That's not cheap.
Comment #4
boombatower commentedLooks like we need someone to take the time to debug this.
Comment #5
catchWe do, but the issue is definitely there, so it should stay active.
Comment #6
fgmJust an idea about this: how about forcing a MEMORY engine when creating the simpletest tables, if one exists ? It should greatly speed up creation, tests, and cleanup of the test DB. Isn't it more or less what the t.d.o. slaves do ?
Comment #7
boombatower commentedYes, they are configured to run mysql in memory using a variety of methods including tmpfs. Seems like a reasonable idea, I'm not sure if there are any reason not to.
Patches welcome.
Comment #8
damien tournoud commentedAs far as I know, Drupal cannot run with MEMORY engines.
Comment #9
boombatower commentedSeems like a good reason. :)
Comment #10
fgmThere is indeed a problem: the MEMORY engine does not support any sort of blob column. So I only changed those tables which did not include some sort of blob (had you noticed how many blobs we are using ?), and didn't notice any problem in an interactive session. Not to say there wouldn't be any, but nothing obvious.
This sad part is that when cloning the DB, simpletest creates the tables with the default engine, not respecting the engine of the original table being cloned. Wouldn't that be a bug ?
I also did a few tests to try optimizing runs a bit, by varying the file system hosting the DB, and by using stock D7U7 or by tweaking the default engine in
database/mysql/schema.inc(currently defaulting to'InnoDB'). In summary, normalizing durations:'mysql_engine' => 'MyISAM',: disk-based 60'mysql_engine' => 'MyISAM',: ram-based instance: 45So FWIW it looks that, at least for testing on that specific machine, the combination of a ram file system and forcing the engine to MyISAM instead of InnoDB is a clear winner. Dunno if that would translate to the t.d.o. testing slaves.
Comment #11
damien tournoud commented@fgm: That's exactly what we are doing for a while now. This, combined with concurrency, allow us to run the full test suite in about 4 minutes.
Comment #12
damien tournoud commentedLet's try that anyway.
Comment #13
dries commentedPerformance tests? :)
Would be nice if the tests results (e.g. http://testing.drupal.org/pifr/file/1/513592-registry-speedup-md5.patch) reported execution time. Wouldn't be very academic but still useful.
Comment #14
fgmContinuing tests, with this morning's HEAD (≥ 2 runs per scenario). Without DamZ' patch, then with it, normalized to HEAD defaults:
So overall, the patch is significant when both engine and storage are is already optimized, meaning PHP load becomes is no longer dominated by DB load.
Comment #15
Anonymous (not verified) commentednice idea damz!
any false positives would be very rare and only cause a file reparse, which is no big deal.
false negatives would be even rarer. +1 from me.
Comment #16
Mike Wacker commentedFYI, I've ran Simpletest on both Drupal 6 and Drupal 7 and definitely notice the speed difference mentioned in this issue.
Comment #17
dries commentedI'm OK with this so I'm marking this RTBC -- an extra review wouldn't hurt.
Comment #18
dries commentedCommitted DamZ's patch. Thanks all!