Friday, July 9, 2010

TurboGears and Amazon EC2 Benchmarking, Part 3: What I was Testing

I actually learned a few things, some of which were surprising, some of which were not. One thing that I don't think I've communicated very well to my readers is that I most emphatically am not comparing TurboGears to any of the other frameworks out there. I'm comparing TurboGears to itself, and finding out what I need to do to scale it up.

I could compare to Ruby on Rails, CakeWalk, CodeIgniter, WebCore, Django, and a host of others. The problem with doing so is that doing that sort of comparison is nearly impossible. Why? Each of these frameworks has their own particular pluses and minuses. PHP versus Python vs Ruby. Pure unadulterated speed vs size of community vs how much scaffolding you need to build vs how locked in you are after you start using it.

For every developer, these are tradeoffs. Some will be okay with scaffolding. Some demand PHP. Others want the framework to put no demands on them. Comparing all of these frameworks in an unbiased fashion just is not feasible. That's why I didn't do it.

All of these, from very very slow to very very fast, will serve the needs of a great many web sites. Even at a "mere" 10 requests per second, that's 864,000 dynamic page views per day. I happen to participate in a forum which transfers around 3G of data every day, and it only gets 380,000 URL requests per day (both dynamic and static).

This is part of why I've stressed that I'm testing the whole application stack so very much in these past few posts. Any of these frameworks are more than capable of serving a rather large and thriving community on very simple hardware.

So, think about those numbers long and hard before you say that a "mere" 14 requests per second is not good enough. If you actually analyze your needs, you're likely to find that you're overly focused on a number that won't matter nearly as much as you think it does.

No comments: