I was unable to locate a satisfactory benchmark of PDO vs. ADOdb, so I decided create some to get an idea of the performance differences.
I expected PDO to beat ADOdb easily, since PDO is a native PHP library and requires no run-time include. See my Web App benchmarking methodology here to understand why I was unsatisfied with the existing PDO vs ADOdb and PEAR::NET library benchmarks I found online.
PDO vs ADOdb Benchmark - Select and Loop
MySQL SELECT Benchmark Results, 1000 Requests, APC Disabled
Library | Concurrency | Total Time | Requests/Sec. | Speedup/Slowdown |
---|---|---|---|---|
ADOdb | 1 | 20.90/sec | 47.84 | - |
PDO | 1 | 0.73/sec | 1358.62 | +2840% |
ADOdb | 50 | 10.78/sec | 99.23 | - |
PDO | 50 | 0.54/sec | 1850.90 | +1865% |
ADOdb | 100 | 10.44/sec | 95.78 | - |
PDO | 100 | 0.53/sec | 1869.33 | +1952% |
APC should give ADOdb an advantage, here are the results of the same benchmark with APC enabled. The performance times for the PDO benchmarks with APC enabled did not change significantly as there were only 3 lines of code for APC to cache.
MySQL SELECT Benchmark Results, 1000 Requests, APC Enabled
Library | Concurrency | Total Time | Requests/Sec. | APC Speedup |
---|---|---|---|---|
ADOdb | 1 | 1.65/sec | 604.52 | +1264% (vs no APC) |
PDO | 1 | - | - | +225% (vs ADOdb) |
ADOdb | 50 | 1.25/sec | 798.26 | +795% (vs no APC) |
PDO | 50 | - | - | +232% (vs ADOdb) |
ADOdb | 100 | 1.33/sec | 751.72 | +785% (vs no APC) |
PDO | 100 | - | - | +249% (vs ADOdb) |
Conclusion
If performance is critical, don’t consider ADOdb unless an optimizer such as APC is installed. Even then, I do not recommend ADOdb unless ADOdb offers some critical feature that is missing in PDO. Even with APC installed the best run of ADOdb was 225% slower than with PDO.
Why? PDO is a native compiled library and not loaded at runtime.
What about PEAR::NET? I have never used this library so I didn’t go to the bother of including it in my benchmark. Also, the purpose of this benchmark was to demonstrate the speedup of using the native PHP library vs a large included library, and I feel that the PEAR library will perform in a similar fashion as the ADOdb library if it is anywhere near the same size and complexity. That is an assumption however…
Addendum
6/5/2008
I was questioned on my choice to exclude ADOdb with the ADOdb extension from this benchmark. I had given it little though at the start of this benchmark and decided to run the benchmark again to compare ADOdb with the extension installed to PDO’s best performance. I ran each benchmark here with and without APC enabled.
MySQL SELECT Benchmark Results, 1000 Requests, ADOdb Extension
APC | Concurrency | Total Time | Requests/Sec. | Slowdown vs. PDO |
---|---|---|---|---|
No | 1 | 18.38/sec | 54.39 | 2498% |
Yes | 1 | 1.63/sec | 613.87 | 221% |
No | 50 | 9.98/sec | 100.18 | 1848% |
Yes | 50 | 1.13/sec | 878.63 | 211% |
No | 100 | 9.75/sec | 102.55 | 1823% |
Yes | 100 | 1.2/sec | 832.71 | 224% |
My conclusion regarding the ADOdb extension: Using my benchmarking methodology, there is little gain to be had with the extension enabled vs without it. I feel this is due to the fact that the ADOdb library must still be included at runtime even with the extension enabled in php.ini.
In my environment, to get within almost half of the speed of PDO, I need two PHP extensions enabled - APC and the ADOdb C extension. PDO remains my recommendation for a database abstraction library from a performance standpoint.
Another addition regarding my test environment: Intel Duo 2Ghz, 2GB RAM, Ubuntu 7.10, PHP 5.2.3 CGI, lighttpd 1.4.18. The disk is slow (5400rpm) so I suspect the slower IO is is increasing the library inclusion load time.
Hi! i’m brasilian and i think you can help me…
How you use the PDO with APC?
Thanks!
[...] It works in very much the same way as ADODB does, and because it is natively executed, offers substantial performance gains. Full list of PDO [...]
a question:
ADODB has some kind of pecl package of it’s own, this will speed up ADODB a lot.
Can you try to do the test again with this pecl extension?
Also, to be more precisely, I recommend you to test all CRUD instead of only R.
And I’m not sure if the database table engine (MyISAM or InnoDB) will effect the result.
It could be a very interesting thing.
Actually, I’m working with a big framework which are using the old mysql query way (which is using function like mysql_query, etc.). I’m considering to change it to either:
1. PDO
2. mysqli
3. ADODB or other third-party libraries.
Can you give me some advices?
Please mail me if possible, thanks.
Zhou Yanqin,
I recommand you more or less the same thing as explained in this blog item :
- ADOdb has some intresting features, BUT it’s a quite large php library. Loading this library has a huge performance hit on the server, because of a quite high IO needed to load the library. On a high loaded environement, this is a big drawback, even with accelerators. For me it’s clearly not a choice to consider on a high loaded production environnement.
- mysqli will probably be the best choice if you plan to never change your DB backend and want the highest performance.
- PDO will probably be the best choice if you have some plan to be able to change yout DB backend (for exemple switch to pgsql), because it will highly reduce the migration impact (less code to modify), at a not so big performance hit. Moreover, the OO design in PDO is interesting (similar to perl DBI)
So I think your choice will be : portability or pure performance.
Personnaly, my choice is portability with PDO that helps to reduce developpement costs.
To further improve ADOdb’s performance, read “High Speed ADOdb” at the following: (scroll down 75%)
Also, set ADODB_PREFETCH_ROWS to 100 in adodb-ext/adodb.c before building. The default is 10. This will increase the performance for Oracle.
For folks connecting to Oracle, ADOdb is actually fast. Just read up on “High Speed ADOdb” and increase the value for ADODB_PREFETCH_ROWS before compiling the extension. Remember to use an accelerator such as APC.
[...] the code is moving from ADODB to PDO as the database interface layer. This gives us a significant performance increase, and it’s arguably the direction PHP is headed, but the real reason I made that move is [...]