When Did Performance Stop Being Important?
Now that I’m finally starting to “get” the Zend Framework I’m starting to have some serious doubts on whether I made the right choice; not in choosing Zend over another framework but in choosing any framework at all. The memory usage is just abysmal across the board and after working with the Zend Framework for about a month or so it’s not entirely clear if it’s going to scale as I need it to.
When Did Performance Stop Mattering?
Which lead to the question of why. At the moment it seems like a question of speed of development versus performance (which is ironic because Zend Framework is not easy or speedy to develop with).
<disclaimer>
To be fair, it’s not just frameworks that have an uncomfortable overhead. Just take a look at Joomla and Drupal; 2 popular content management systems with an absurd overhead. It’s just easier to focus on my current interest rather than the CMS’es.
</disclaimer>
One thing I’m having a hard time getting comfortable with is how much memory is required when using a php web framework. Out of the box both Zend and Symfony (for example) use around 5MB per request. Understand, this is without any custom code. Just setting up the MVC and Autoloader for the default views and models. Nothing impressive or useful and 5 fucking MB to run that?
After having been on the wrong end of this issue on my own code I’m pretty sensitive to how my code performs; I’ve written some nasty algorithms and watching them crumble in real time has a tendency to turn you around 
Researching the issue doesn’t really help. There’s a lot of advice on how to improve the performance but it seems to always center around common sense improvements you should be using anyway.
The most touted improvement I’ve heard is that you have to use a PHP accelerator and opcode cache. I just find that response flawed but not because it’s bad advice but because it’s common sense. Yes, it’s true, but not using a framework in combination with a PHP accelerator and opcode cache is still better in my experience. All relying on those tools does is move the baseline for performance, which you’re supposed to do already, and a framework still consumes a good amount of resources on it’s own.
In my experience you get about a 50% reduction in memory usage when using something like x-cache but using the Zend Framework still leaves a total of 2.5MB of memory usage to accomplish the bare minimum setup.
One saving grace is that hardware is cheap. Scaling with hardware is usually the go-to escape when the bottleneck is the code but it’s not without it’s own set of issues. For one thing while it’s true that hardware is cheap the labor to maintain that hardware is not. Especially if you want to maintain the server in a proper and responsible manner.
Another option, that’s really only available when using the Zend Framework, is decoupling the project from a direct dependence and not use the MVC components. In anticipation of doing this I’ve been writing a lot my recent code and projects in a style that’ll allow easy(ish) separation when the time comes.
At this point I haven’t used a framework in a production environment so all of this consternation might be for nothing. I just have a hard time accepting the performance hit of half a MB for using something trivial like a content management system (drupal) or, for example, a component like Zend_Navigation compared to the benefit. What are they actually doing to make the cost worth while?
Still another option is to just walk away from this whole OOP thing and head back to the familiar touch of procedural php and using functions and classes as more of decorators to apply than core components. From my personal experience, and only my experience, using OOP is way more expensive than procedural. At the end of the day I need my programs to work fast, be easy to operate for my users and have a low impact on the server. How does using OOP help that?
At the moment I’m not sure how this is going to work out. I am confident it’ll be an adventure though. Hopefully, I find out how Zend will scale before a project of mine goes viral or gets popular. Hopefully.
Email
Never prematurely optimize. Unless you are working on the next Facebook, Zend Framework will scale fine. Your bottlenecks are going to be in database, filesystem and web service calls, most definitely not with using OOP code (the performance gains from using procedural PHP are nigh-unnoticeable and not worth the loss of maintainability/portability). Even if your application does reach the stage where it is serving several hundred million requests per day, it will not matter what PHP framework or coding style you are using, as you will need to rewrite your PHP backend in a real language like C, Java or Python.
I don’t think I was talking about premature optimization (blame my bad writing for any confusion
).
To me, premature optimization involves rewriting and restructuring chunks of code that has yet to be proven necessary or useful. This is not what I was talking about.
No, what I was trying to convey was noticing the HUGE overhead while doing trivial things like bootstrapping and database calls. I’ve learned it’s just, well, frankly, naive, to blindly develop without knowing the impact your development is having on the stability and integrity of the project as a whole and so I am always keeping an eye on my development.
That being said, I have (just today) uploaded my ZF site to my production server for testing and noticed just an amazing decrease in memory and CPU usage. On my development machine (using php 5.3 & Apache 2.2) each page was taking around 7MB of memory. On my production server (php 5.2.11 & Apache 2.2 with PHP Accelerator) each page was taking about 1.5MB so there was a pretty impressive improvement from development to production.
When it became cheaper to throw hardware at a performance issue than having a developer try to squeeze speed out of their codebase.
if a framework won’t let you be more productive, then do it: go, ditch it. your procedural, and (hopefully) mixed php/html scripts will definitley run faster, with less memory consumption (welcome back, 1995!).
also, you could program all your pages in assembler/c/go/haskell (oh no, forget the last one – haskell definitley needs more ram than plain c) – that will even speed them up a bit! response time down to 0.032 secs insted of 0.037 seconds! yay, gratulations!
even better, write your own webserver specialized in what you want to do! can you even imagine what overhead apache/nginx/lighttpd imposes on your requests?
you’re certainly writing the new reddit/facebook/twitter, so obviously expensive frameworks aren’t for you. if your script needs 1,5mb per request (as you said in your comment), your server are capped at ~2,600 concurrent requests (memory-wise, don’t get me startet on response-time!), assuming 4gb of available memory (wait, twitter is partly built on ruby, the one of the slowest languages known to man, d’oh).
i can’t think i ever read something as dumb as accusing OOP as being too slow for web developement. i have to stop and cool down now. good luck going procedural.
C’mon man, calm down; you’re showing your ass a little here…
You laid out kind of a rant (albeit, with some points buried inside that left me with questions) and for the sake of anyone else who reads this I wanted to respond. And yes, I admit, I couldn’t really help myself from responding either.
First, I was using the move to procedural as an option (yes, a bad option) for fixing the issues I was seeing at the time. I honestly thought the absurdity of the statement was obvious when I was writing it. My bad on thinking people wouldn’t jump at a chance to show how smart they are I guess.
–
Then you rant some more with nothing to respond to. It kinda speaks for itself… (Congrats on the Haskel reference).
–
Next, who said anything about building a reddit (or similar)? And why would I have to build a site on that scale to worry about performance and resource usage?
Lastly, I never said anything about OOP being too slow for web development. What I was doing was posing a question about the resource usage I saw during development. Hell, I even pointed out in the above comment, when the memory usage dropped from 7MB to 1.5MB, that framework performance wasn’t an issue.
sorry, i was a bit irate yesternight – i worked through the whole weekend, and i was very tired. was i wanted to say:
* if mvc-frameworks don’t increase your productivity, you may do something very wrong. for small projects i used a certain (mvc-)microframework a lot, and i love it. it feels like a big step in evolution, and i love how incredibly fast i’m able to implement small projects.
* procedural programming may be a nuance faster and more memory efficient, but it makes developement hard. i have to work with a huge (homegrown, but not by me) 1998-style php3 procedural programming cms at work, and it’s dev hell. mixed php/html, no oop, untestable, … – sorry i got worked up a bit, but i have to deal with this on a daily basis, and it’s NOT FUN.
* you may be right: for some huge applications (like reddit, facebook, …) with trendemous traffic a full blown framework may be too slow and/or memory hungry. it may pay off to write everthing from scratch there, on the other hand, additional machines are often cheaper in this case.
* normally, dev-time is more expensive than hardware.
* “OOP is way more expensive than procedural” – true. but is it TOO expensive, performance-wise? definitley not. a project often gets expensive when it comes to maintainability, though. and in almost all cases, procedural programming is definitley harder to maintain than a nice, oop’d mvc-application.
* almost all php applications spend more time waiting for the database than script execution itself.
* in my personal experience, i encountered 2 projects where “php was too slow”, and both times it boiled down to bad algorithms (n², anyone?). ok, there was one more time, when the whole CMS was used to answer a trivial ajax request. as soon those got rewritten, everything went smooth again. and as soon as you’re able to enable caching (not possible everywhere, but still), performance really doesn’t matter anymore!
* you know the old saying: it doesn’t have to be really fast, it just has to be fast *enough*
* “at the end of the day …” – may be at the end of the week, if you don’t go for maintainability and ease-of-developement. optimizing in the case of going viral will certainly be cheaper than maintaining prematurely optimized code.
sorry, i didn’t want to be impolite, but your article was just too absurd.
going back to procedural programming … heh.
No worries man; after hearing about your day your response makes complete sense. I’ve actually had to do the same thing so I definitely feel your pain.
You make some good points and I agree with you pretty much across the board but with a couple exceptions and notes:
About the productivity: hell yes, using a framework increases productivity. Once you learn it that is. At the time I wrote the post I was in the throes of learning ZF and, as I’m sure you know, ZF has a hell of a learning curve. Was it unfair of me to blame all frameworks for this? Yes it was. 100% my bad on that. You could relate my mindset at the time I wrote the post to yours when you responded
Since getting up to speed with ZF I’ve definitely seen the light in framework land though I still reserve the right to hate specific frameworks (I’m looking at you Akelos).
People always tout that hardware is cheap; it’s a cliche at this point. It is true that adding hardware will solve pretty much all software problems but that’s only true if you can actually get the hardware (I’ve had problems with this way too many times).
For example, I’ve worked at places where getting money for hardware wasn’t easy (almost impossible) and would require HUGE amounts of notice, research and preparation (read: reports). On top of that the programmers would be responsible for maintaining and managing the new hardware. Not the norm I know, and that probably has more to do with my perception of performance than anything else. Consequently, I’ve never seen the logic in counting on hardware to fix performance issues except if there was nothing else left to do. In hindsight, probably not the healthiest outlooks.
That being said (and because I think you called me out on this); I’ve always been careful about NOT prematurely optimizing anything. I get how absolutely stupid that would be. I’ve personally seen programmers waste days making tweaks to code that amount to nothing significant in the grand scheme (and then having it all undone through QA). As you pointed out in your first comment a hundredth of a percent decrease in time is meaningless in the grand scheme.
Thanks for the insight. I feel like this discussion added to the post.
to be honest, for most of my (private) projects i don’t use a full blown framework like ZF, but a very lightweight microframework (something like http://github.com/bastos/nicedog).
very small, very fast, and it certainly got nothing i don’t need
It sounds like you are emulating Rasmus a bit, Eric.
I used to be a huge proponent of PHP frameworks, specifically The Zend Framework. Then I spent the last year on Objective-C and C land developing an iPhone app. Coming back to a middleware environment from an environment where real estate was ALWAYS a factor, I feel that PHP is just not a language upon which one should build a framework.
Of course, PHP has its place. All languages do. But PHP’s place is outputting to the browser. You’re kidding yourself if you want it to do more than that, save for some low-level file operations or database queries. This is precisely due to the nature of the language itself: every request involves the re-instantiation of objects. If you throw enough objects into the mix, you lose performance.
Sure, most servers can handle these requests with relative ease, but if you throw enough traffic at them, they will start to throttle much sooner on a PHP stack than a J2EE, .NET, or even Django setup.
That said, there are some Java tie-ins for PHP (such as the PHP-Java Bridge http://php-java-bridge.sourceforge.net/pjb/) that let PHP do what it does best.
I agree that microframeworks are a good solution for small sites as long as there’s some caching implementation involved.
TLDR: I agree with OP.