; ?>/images/rss-18x18.png "Get the Feed"){kind=small}
PHP Frameworks and Scaling
This article covering a talk by Rasmus Lerdorf on the issue of scaling PHP and PHP Frameworks is a couple of months old but keeps popping up on Delicious. There’s a lot to disagree with there, especially if you read through the comments by other people who were in the audience for the talk, but the thing that stood out for me benchmarking covered in the “Hello World” section.
Please please please tell me the reporter misunderstood Rasmus’ point, as some have suggested in the comments section. I can only hope Rasmus (who, btw, is a vocal member of the Nike+ Running community that I work on at R/GA and has written the SlowGeek site to improve on some features he felt we were lacking) would not make a big deal out of such a naive example. So you’re telling me that “Hello World” printed out directly from a PHP file is orders of magnitude quicker than “Hello World” printed out through a PHP Framework? Amazing. I will immediately concede that if your intention is to write and scale a “Hello World” application CodeIgniter or other PHP frameworks are not for you.
It’s like saying that it takes longer to get to the corner store if you take you helicopter as opposed to walking. Sure, you have to suit up, start up the rotors, take off, find a good landing spot, step over the dead bodies, etc. But that’s not practical is it? Either is a “Hello World” example.
Look, I’m perfectly willing to accept that CodeIgniter will be slower than a hand-crafted framework when all is said and done. That alone is the reason I don’t use any ORM in my code. It can’t possibly be faster. But for something at my scale it makes configuration, development, and maintenance very easy. And in the wise words of the fine developers at Coding Horror, programmers are expensive and hardware is cheap. To a certain scale, you can just throw hardware at your problem.
That said, I’m sure Rasmus understands that and the reporter took him out of context. Right….?
4 comments
The entire point was that people need to understand the cost of their convenience. The “Hello World” example shows the cost of the framework if you don’t use any of the features in the framework itself. As you start to use more and more features, the cost is reduced. If you use every single feature, then you have the perfect framework.
However, in reality people only use a fraction of a general purpose framework, yet they incur the overhead of the entire framework. What I was trying to get across in the talk was the methodology by which you can measure that cost and make an informed decision when it comes to trading off convenience against performance. There is nothing wrong with using frameworks, but there is something seriously wrong with making the decision to use one without understanding the cost penalty.
Point taken Rasmus. This is along the lines of what I was assuming you meant, and it’s obviously inarguable. Any framework in any environment incurs a penalty. The bigger the framework, the bigger the penalty. Thanks for your comments. I’m honored to have you visit my blog and consider my writing.
Of course the other cost, which is very big and real, is that of migrating to a framework when additional needs arise. Businesses that can’t afford to have developers on staff should probably always demand at least a basic CMS. If they’re lucky enough to have site performance as an issue, front end tweaks like Minify are easy to slap in place and switching hosts is easier than migrating content from a homebrew system/flat files.
True. Similarly it’s worth considering the cost of other “invisibles”, such as maintenance cost, learning curve (for new developers on the project), and application security (e.g. SQL injection attacks). A good framework addresses each of these issues. Don’t get me wrong, I’m don’t believe everyone should be using a framework. I generally despise Java frameworks. But I also think most sites could be well-served by them because most sites never end up having to scale to the point where it becomes an issue.