I am running PHPUnit to test a CodeIgniter application using CIUnit (a third party interface between the two). A number of the tests select data from an empty MySQL database that is populated with 5-10 records in setUp(). On Windows and the web server (Ubuntu 10.04/Apache 2.2/MySQL 5.1/PHP 5.3), the 105 tests run in 2-3 seconds with a memory usage of around 30mb. On my local (Ubuntu 12.04/Apache 2.2/MySQL 5.5/PHP 5.3), the 105 tests run with the same memory usage, but take approx 45 seconds.
I have narrowed down the slowness to tests which utilise the database; are there any configuration settings that I am possibly missing that are making the tests run 15 times slower? If not, would my best bet be to try downgrading MySQL, or maybe even Ubuntu (I have already tried downgrading from 12.10 to 12.04)?
Any answers much appreciated.
You are most likely running into the performance hit created by barriers being default on in the ext4 filesystem. Read more of them here:
Here's what they do from the docs:
barrier=<0|1(*)>
the jbd code. barrier=0 disables, barrier=1 enables. This also
requires an IO stack which can support barriers, and if jbd gets an
error on a barrier write, it will disable again with a warning. Write
barriers enforce proper on-disk ordering of journal commits, making
volatile disk write caches safe to use, at some performance penalty.
If your disks are battery-backed in one way or another, disabling
barriers may safely improve performance.
You can try to remount your filesystem without them like this (use the mount point where the mysql data files are living)
mount -o remount,nobarrier /
In my environment this makes a Tests: 83, Assertions: 194 suite's runtime reduce from 48 seconds to 6.
I was able to significantly speed up my PHPUnit tests by following this suggestion [1]:
If you are using the InnoDB engine (the default on Fedora), try putting this in your my.cnf database configuration:
[mysqld]
...
innodb_flush_log_at_trx_commit=2
...
then restart your server.
It does seem to reduce the reliability of your database, IF you get a power loss WHILE writing etc. It was definitely an acceptable rick for my development machine, but I wouldn't recommend it for production. See more details about the reliability at [2].
[1] http://aventinesolutions.nl/mediawiki2/index.php/PHPUnit:_a_Quick_Way_to_Speed_Up_Test_Suites?goback=.gde_1685627_member_107087295
[2] http://dev.mysql.com/doc/refman/4.1/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit
