MageDB progress update – disappointed in Zend

Hey,

I did some major work on MageDB again. This time to make the code that i currently have more structured. And the results look nice.
For example the inclusion of sub pages on a page used to roughly take 40 or 50 lines of code (with all the if elseif elseif … else + checks + include lines) but right now that part is down to 16 lines with enters and handles 4 pages (view, download, post_comment and rate) this can be done in less lines but will become ugly or look strange.

Other things i did in MageDB was rechecking the input values if they where really safe. They where not thus i needed to fix that up. It’s now way shorter and a lot more strict.

For the rest i did performance testing of the current MageDB codebase. That is without the template engine (Dwoo) since i didn’t include that one yet. I came to very surprising results compared to the latest paFileDB (not downloadable because there site is offline and seems just dead). I had expected MageDB to run faster then paFileDB but sadly that’s not the case. In terms of requests per second (ab — Apache Banch) MageDB gets roughly 900 requests per second (lighttpd + php + APC module) and paFileDB gets roughly 1200 requests per second on the same setup! that’s roughly 33% FASTER then my MageDB script. But i do think that the current MageDB code-base is way more suited to heavy load then paFileDB was.

Anyway. that unpleasant surprise made me wonder what was taking up the resources so i installed XDebug and did some traces on MageDB and paFileDB. It turns out that MageDB had roughly 2x more function calls then paFileDB and is roughly 1.8x slower then paFileDB. Now what caused that?
Zend sadly is the source of the problems. I already found out that it’s including a shitload of classes (thus also files in zend’s case) and that alone makes everything run a bit slower. Then the parts of Zend that i use right now: Db (for mysql), Translate (to support multiple languages), Registry (nice way to have global variables in a clean way) and the Autoload for zend itself. Now my guess is that it’s including roughly 40 or even 50 files because 1 simple test with only 1 zend module being used resulted in 30!!!! classes (thus files) being included.

So what am i going to do about this? Well at some point in time i will just (again) drop Zend for being a time ans resource hog. I will only have to recreate the classes Registry and Locale and use just php’s mysqli without a wrapper. It’s not like i was planning to support anything other then mysql anyway although in the long run i would have liked sqlite and postgresql support as well. For right now i probably just continue where i left and keep zend in it for now.

The things i have to do now before i can start working on the admin panel:

• Making a very strict and fast category caching system since category calculations are heavy on php(recursive checks and thus a lot of loops) and on mysql(i’m grabbing all category data at once…).
• Including Dwoo as the template engine

And btw. My goal in requests per second on my hardware and the above named setup is to have 1000 requests/second on every page that MageDB has. Just for comparison, phpbb has just a pathetic 44.97 requests/second and that is with the above mentions setup! Note: just having APC installed is a rough x2 or even x3 speed improvement.

That’s it for the MageDB news,
Mark