I’ve chosen Turbogears for a recent web project. Up to now, I was pretty happy with this choice, as it allowed me to made changes to the application rather easily, I happen to like KID templating, and it all was rather painless.

However, I’m stuck at two place right now. One is a rather expensive database query I have not yet added - I know that it’s going to be expensive, and I’d need some way of caching the results easily. I havn’t found a “turbogearish” way of caching these interim results yet.

Since that brought me onto the performance thing - when writing an app you don’t really know yet how it will be implemented, you best postpone performance considerations a bit, so you don’t optimize too early - I did some measurements. And was pretty disappointed by the results.

The testing virtual machine (sorry, I don’t have hardware specs for the actual machine) is rather slow. But still, static apache can serve some 450 requests per second. Turbogears will serve static files at ~22 r/s and the main page of the webapp at just 4.5 r/s (measured with siege, when it’s not crashing).

I tried switching from sqlite to mysql in Turbogears, but unfortunately that just makes the application crash altogether at some point (no SQL queries succeed anymore: ‘Page handler: “Commands out of sync; you can’t run this command now”’)

Notice that this was by no means a fair benchmark of Turbogears (I’m not a turbogears expert, and the little documentation I’ve found so far didn’t help me at all in optimizing it’s performance). I was just evaluating where I’m at, and now I’m about to decide where to go next.

So can anyone point me to some docs on how to get turbogears up to an acceptable speed (where acceptable would probably be >20 r/s on this hardware)? Otherwise I guess I’ll start a rewrite now, maybe using Java JSF and Facelets. They seem to be a good choice if you want XML-based templating.

Don’t even suggest PHP to me, it’s crap. And I won’t be trying Ruby on Rails next, either. I don’t need rapid prototyping anymore, but can go for the high-performance implementation now, even if it will be harder to read, write and modify. I have now a better grasp for what I need and how the architecture of the app should be like.