I took the time to have a look at the DBAL extension today which enables TYPO3 to use other databases than MySQL which is a killer feature that every better web framework should offer. DBAL uses adodb for the actual database access but has another layer on top of it which seems to do quite a lot a SQL shuffling, at least so I heard in the -core list.

I know that a lot of the notoriously bad TYPO3 extensions don’t use the DB API for data manipulation, and that’s a commonly cited reason for not using it. However, I was interested in two core issues:

1. How well does the TYPO3 core work with DBAL?
2. How big is the performance penalty caused by both DBAL and adodb?

Setup

The first question is easily answered by trying a native install according to the manual (which is slightly outdated because TYPO3 now ships with the required extensions). After modifying localconf.php and trying the install tool, I did get quite a few ugly error messages, but the installation is usable. The installation process and the state of the tables (according to the install tool’s db compare) leaves much to be desired, not to mention the usability issues in the install tool.

Benchmark

The second problem required setting up an empty page and benchmarking it with the ab command:

ab -c 50 -n 1000

I did not expect too large differences given that a cached page with the default helloworld template should not require many db requests and therefore not have much impact on the web server performance.

It turned out I was wrong about that, and there are huge differences in performance:

1. The baseline is, of course, native performance with MySQL without DBAL. For the empty default template I got 60 req/s (lighttpd/fastcgi, eaccelerator on), not too bad for an unoptimized desktop with X and other applications running.
2. Turning on DBAL but with the native (=passthrough) MySQL driver shows a horrible performance decline to ridicolous 8.4 req/s. It seems like the suspicions I had about DBAL being actually a fat glue layer seem to be true, but I hardly expected such a result.
3. Using adodb’s MySQL driver did not matter any more, with 7.4 req/s we have a slight performance loss but that’s a fair price for a nice abstraction layer.
4. Finally, I tried to install TYPO3 on a PostgreSQL 8 database and succeeded after another long row of error messages and strange behaviour. Surprisingly, a benchmark with DBAL and adodb’s postgresql8 driver yields 14 req/s. Still a long way from native MySQL but twice as fast as the DBAL/MySQL combination. This result puzzles me a little, I can only offer two explanations: a) Postgres or its PHP bindings are much faster than MySQL, b) DBAL or adodb does some strange things with MySQL.

Conclusion

DBAL needs a major overhaul to be production ready. The installation and compatibility even with plain TYPO3 is a major pain, and the performance sucks. I hope that for 5.0 we get a fresh, slim, clean DBAL layer that does not involve so much computation overhead.