Part of the Google Summer of Code is building a platform for which to test the performance of WordPress and WordPress plugins and themes. The issue with using mysqlnd is that it is still in development, which makes it unstable for production. I do think that by the time I’m finished with my project that both should be stable or nearing production ready status.
I guess that is what I get for planning a project with a prerequisite that is still not complete. Trying the Windows way was a bust. I tried the MySQL mysqli extension with mysqlnd, but it doesn’t seem to work correctly with WAMP5 2.0. I’m guessing there is a trigger that I’m missing with the base install of PHP.
The good news is that PHP 5.3 might come with mysqlnd library by default or at least let you enable it during the installation. I’m hoping that the Windows has an installation that allows you the choice between libmysql and mysqlnd.
The bad news is that PHP 5.3 is still not out either and probably won’t be out for another few months.
Xdebug is easy, since it is stable and can be enabled on both Windows and *nix systems easily. I haven’t gotten around to compiling and enabling Xdebug on a Linux box, so I’m hoping I don’t screw anything up.
I like that Xdebug allows you to install after PHP is compiled. This allows you to make sure that PHP was compiled correctly and test its build. Then test it after Xdebug has been added.
I’ll know within 30 minutes whether I’m going to have to spend another two hours compiling PHP or if I’m ready to go ahead with compiling Xdebug and getting that to run.
For those who are interested, the WordPress Performance Test site looked at. I include the phpinfo for those to see what modules I have installed, but nothing else. The PHP version is on the first page with links to the WordPress 2.5 site and the WordPress Trunk site (currently 2.6).
I might have to add additional WordPress versions for testing, since I’ll have no data for basing the performance tests. I’m only going to work with 2.5 since it is still in active support development and the in development trunk. I think I’m always going to be testing the trunk, but just add additional versions as they come out. If I start at 2.5 or go back to 2.3 or even 2.0, eventually I have enough data for testing the performance and having a margin for what WordPress should fall in.
Right now, PHP execution should never raise above 1 second total time. It will just be going through and checking for functions, which have additional overhead.
If I Develop the WordPress Extension
It would also be interesting to have a PHP installation that has the WordPress PHP extension installed. At least for the Plugin API to see how much it helps. If the current system works, then I’ll build on top of it for testing the WordPress extension. I don’t want to have to install it within PHP, I want to be able to install it into PHP like Xdebug is. It would make it easier for development purposes.
If I do have to keep installing PHP for the WordPress PHP extension development, I think I’ll probably have PHP installed with a Cron Job that takes place every night based off a stable build. It would be interesting to see how much faster it is.
From my past benchmarks, the WordPress Plugin API has the most overhead, not from what is within the functions, but from how much it is used. I would like to test whether or not if the compiled C versions would reduce the function call overhead or if it would be the same.
Possibly Related Posts:
- Paying Off Debt Revisited
- Thou Art God
- Saying Good Bye to Dollhouse
- Where the Wild Things Are Movie Review
- Why Choose 1st Financial Bank?