Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Penfold (7457)

Penfold
  (email not shown publicly)
http://perlent.blogspot.com/
AOL IM: fleetfootmike (Add Buddy, Send Message)
Yahoo! ID: tuxservers (Add User, Send Message)

Perl developer for Yahoo! UK, previously for MindCandy Design and CricInfo.com - guitarist, photographer, writer.

Journal of Penfold (7457)

Wednesday May 16, 2007
02:40 AM

Performance Tests

[ #33287 ]
Every now and then, it rears its head on one or other IRC channel. Someone trots out one of a number of web sites that purports to compare like with like, hammering the crap out of various implementations of a web app in Rails, various Perl frameworks and not-frameworks, J2EE, PHP, etc etc, and attempts to draw meaningful conclusions from the results.

Setting aside, for the moment, brian d. foy's tongue-in-cheek demolition of benchmarking as a valid tool, what do we learn from these?

Actually, mostly, we learn that a single instance of almost any web app written in just about any language on semi-decent hardware, pounded on by JMeter, ab or whatever will cough up well over 100 hits/second without actually breaking into much of a sweat.

Let's stop right there for our first remedial maths class, OK?

100 hits/second.

That's 6,000 hits a minute. 360,000 hits an hour.

Eight point six million hits a day. And change.

And that's page views - c'mon, you don't serve your static images out of of your webapp framework. That's a dickens of a lot of traffic. To give you an idea, CricInfo.com's record month while I was there was a quarter of a billion page views... that's about 8.3 million a day on the biggest single-sport website on the net.

You're expecting that amount of traffic? Paying for the bandwidth is going to be a much bigger worry than whether your web app framework can cope.

Stick an ad on every page, from Y!, Google, whoever. A week's traffic, tops, and you can afford another server. Hell, you can afford two and a load-balancer. And quite frankly, your rate-determining step is almost certainly NOT how fast your underlying development framework can generate the pages, but how well-written your code and your DB are, how cacheable the pages are, how big they are, and how laggy your average client is. One missing database index can turn a 0.02s query into a 3s query.

Get over it, folks.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Note that a site with a quarter billion page views will not typically experience a nice, convenient traffic flow of 95 sustained hits/sec. It’s more likely to be 10 hits/sec a lot of the time and 600 hits/sec at certain times (e.g. for a sports site, maybe right after important matches), averaging out to 95 hits/sec.

    Web traffic is often very bursty.

    But even that hardly affects the point in question. Most people can only dream of having scalability problems.