LicenseSyndicate This BlogPlanet PHPFirst year of Qaiku, and a travel writing challenge - Henri Bergius
Tuesday, March 9. 2010 Getting started with the Midgard content repository - Henri Bergius Tuesday, March 9. 2010 Neural Networks in PHP - PHP Classes Tuesday, March 9. 2010 CMS Watch on their Midgard usage - Henri Bergius Monday, March 8. 2010 Upgrades In Open Source - Brandon Savage Monday, March 8. 2010 Seed doc updates, and Gio async directory listing - Alan Knowles Monday, March 8. 2010 My NAS - QNAP TS 119 Turbo NAS - Andrey Hristov Saturday, March 6. 2010 PHP London Conference: In Review - Lorna Mitchell Friday, March 5. 2010 Do you queue? Introduction to the Zend Server Job Queue - Zend Developer Zone Friday, March 5. 2010 Creating Scalable Vector Graphs with PHP - Zend Developer Zone Friday, March 5. 2010 StatisticsLast entry: 2010-02-23 23:27
405 entries written
1496 comments have been made
|
Tuesday, February 23. 2010
Posted by Pádraic Brady
in PHP General, PHP Security, Zend Framework
Comments (46) Trackbacks (0) Related entries by tags: Is PHP A Worthy Template Language? Well, of course it is... The Mysteries Of Asynchronous Processing With PHP - Part 3: Implementation With Spawned Child Processes Using Simple Scripts Or Zend Framework The Mysteries Of Asynchronous Processing With PHP - Part 2: Making Zend Framework Applications CLI Accessible The Mysteries Of Asynchronous Processing With PHP - Part 1: Asynchronous Benefits, Task Identification and Implementation Methods Zend Framework Monthly Bug Hunt Starts Today - C'mon, Join In! View as PDF: This entry | This month | Full blog PHP Framework Benchmarks: Entertaining But Ultimately Useless
Some recent attention in the PHP framework community has been focused on the recent publication of Symfony 2 Preview benchmarks showing that Symfony 2 outperforms Zend Framework by a factor of 3.5. It also outperforms every other benchmarked framework. This reminded me of the earlier Yii Framework benchmarks which allegedly proved that Yii outperforms Zend Framework by a factor of 7. At this point, the spirit of Glenn Beck would have me demonstrate that 3.5 multiplied by 2 (the number of eyes in Barrack Obama's skull) equals 7, thus proving the existence of a Liberal conspiracy led by a closet Muslim. That's probably bullshit though.
My fellow Zend Frameworkers, we cannot allow this to stand. We must put paid to these wild claims and prove, once and for all, that Zend Framework is the fastest. To present this undeniable truth rooted in solid statistics and Paul M. Jones (aka Benchmark God) inspired techniques, I have created the benchmark of benchmarks. Well, to be honest, I only really edited another benchmark. But still, it will prove Zend Framework is faster than everything else out there. Before everyone gets too excited, the Symfony 2 Preview performance is quite impressive and it's consistent in my own rerun of the original benchmark. A lot of effort has obviously gone into speeding things up and it shows. My benchmark is not about busting some untruth, but about demonstrating how it is possible to outrace Symfony 2 and Yii with the Zend Framework. I'll dissect the methods after the results are reported To ensure the unchallenged fairness of my benchmark, I will publish its entire source code to Github. Unless there are any more sarcastic Irishmen out there, that should be relatively safe. I will also follow in the path of the Almighty Paul M. Jones, in whose shadow all PHP framework benchmarkers will find peace, flowing waters, milk and honey and, if not too much trouble, the extermination of all console noobs who insist that PC gaming is dying. Is that too much to ask, Paul? A little biblical gnashing of teeth would do them good. Paul (may he live forever) promotes using a standardised benchmarking platform, so I will be using an AWS instance reflecting Fabien Potencier's except it will be an m1.large instance instead (the other seeing a few issues in testing) and include some baseline HTML to make sure siege or ab are not misbehaving. With all these preparations, the stage is set to demolish Symfony 2 and Yii and run them into the ground. Prior to running the benchmark, it's suggested to play the Battlestar Galactica theme tune in the background to set the right mood. Just think of Fabien Potencier dressed up as a Cylon (if only my Photoshop skills were better...sigh). It fits in well with the siege feedback. You can try some HipHop, but those Facebook guys must have been smoking something illegal because it had no impact during the Zend Framework runs. I also experimented with Metallica (surely that would work!) but no...nothing. Quite disappointing. For those with attention deficit disorder, here are the results: framework | rel | avg | 1 | 2 | 3 | 4 | 5 As you can clearly see, Zend Framework is faster than all other frameworks. More enlightening, we beat both Symfony 2 and Yii. Lithium and Flow were omitted from the original benchmark because besides them being non-functional when forked from Fabien's benchmark (for whatever reason), they are both fairly young frameworks (Flow3 is alpha). Note: Lithium works fine outside of the benchmark (I've been working with it) and it is fairly fast. Zend Framework wins. You can go now. Still here? I suppose you're trying to figure out how I manipulated...er...improved the benchmark to reflect my reality of Zend Framework being superior at all levels. Well, I'm not sure I should tell you. It's hard enough to create and run these benchmarks without having to explain how to fuck them over so they show whatever you need them to. Alright then, I'll 'fess up. To create a positive benchmark, you need to understand that all frameworks were born as festering piles of unoptimised stinking crap. They were all born bad and get worse with age. This sounds quite sad, but actually it's an inevitable compromise between performance and features. It's also a compromise between performance and ease-of-use. So you see, performance is unfairly faced by two opponents: features and ease-of-use. All performance is sacrificed in the name of serving the needs of rapid development, flexibility, prototyping, and making your source code look prettier than the other guy's. As if. What happens if you move away from the enemies of performance and do some propping up behind the scenes? You get...wait for it...oodles of extra performance! This is partly how both Symfony 2 and Yii manage to outperform Zend Framework. But hey, we can do it too! To ascertain the perfect method of "propping up" to get the Zend Framework into speed demon territory without it costing me dozens of hours of in-depth analysis, I created four variants to play with: All-In, Optimised, More-Optimised and What-The-Fuck-Optimised. Here's the four final alternatives benchmarked against themselves (same run as the previous results). framework | rel | avg | 1 | 2 | 3 | 4 | 5 Pretty illuminating So just how does this miraculous optimisation work to such a degree that we can beat Symfony 2 and Yii at their speed games? There are four solid steps to being a speed demon. I only implemented these in the More-Optimised variant which was enough to destroy Symfony 2 (as configured) and Yii in the benchmarks. The Optimised version simply discarded some optional ease-of-use features. What-The-Fuck-Optimised is identical to More-Optimised except it exits in the middle of a controller (we only had to echo Hello, right? 1. Don't use Zend_Application. While Zend_App is great for creating consistent complex bootstraps within a standardised structure, it doesn't come without a significant performance hit to baseline performance. A more direct bootstrap (typical of ZF until Zend_App arrived) is far faster and can also be done without configuration files. 2. Skip using the ViewRenderer plugin. Without the ViewRenderer, you need to manually configure Zend_View and add render() calls to Controllers. This is actually very simple to do and is fairly fast - fast was never really part of the ViewRenderer's genetics. 3. Use autoloading. Strip require_once calls from the framework library so unneeded files are ignored. Replace uses of Zend_Loader_Autoloader with a not-so-crazy autoloader function. In fact, pray Zend_Loader is never used - it does a lot of file ops that, to date, have never been explained to me as having any value. 4. Preload everything (Symfony 2 Preview does!). It buys you some performance cookies and equalises the speed baseline. Using a simple preload script is not that hard. With these four techniques, Symfony 2 and Yii are left in the dust. It's time to ask the question on everybody's minds: what does it all mean? Give up. There is no meaning in benchmarks. They are designed to compare the relative performance of frameworks with different goals, design philosophies, development practices, and features. Might as well flip a coin, roll some dice or perhaps examine the entrails of a sacrificed goat for answers. The goat is your best bet. If all else fails at least you can have a nice goat-stew dinner while you think things over some more. Benchmarks. Useless. Final words? Know your framework! All this benchmarking nonsense does little good unless it's plastered with disclaimers. Symfony's preloading is an obvious example mainly because it's the only framework in Fabien's benchmark (that I know of) using it. Does it increase base performance out of the box? Yes. Can every other framework use it with little effort? Yes. So what's the point? Should everything else preload by default? Maybe, who can tell. Most developers simply don't work in scenarios where such a performance boost would make a difference. And if they do, it's easy to make the necessary changes. What's interesting is that I just fiddled with the Zend Framework. You could probably find ways of making every other framework in there run a hell of a lot faster than currently presented. It's just a bit sweeter for Zend Framework since we're the self-proclaimed use-at-will framework. And its really fast when developers need it to be. Comments
Display comments as
(Linear | Threaded)
I can't tell if you think I'm an ass, or if you're just being over-the-top. Either way, pretty damn funny.
I'm being over the top
I look forward to that benchmark. Seriously! :-x
Do you know of any good tutorials explaining how to avoid using the ViewRenderer (point #2) and do the preloading (point #4)? I am very interested in both of these ideas.
Avoiding the ViewRenderer just means instantiating Zend_View, passing it to the controller, setting a ScriptPath (for templates), and calling Zend_View::render(). You can do it literally within a controller's init() method or use a simple action helper instead.
Preloading is simply knowing all classes and interfaces being used in a request, and based on those, concatenating all the class/interface code into a single giant file to be included from a bootstrap (as early as possible). You can make it context sensitive, i.e. included only for certain requests. You can also tie different preload files to different requests (some requests use more or far less classes depending on what they do). The purpose of the preload is to skip including each class file individually (that's slow even with autoloading and a realpath cache).
Hey Padraic, hilarious as usual.
Benchmarks aside, I think the preloading thing is actually a pretty interesting idea, especially since it's an effectively free performance win with no code changes and relatively few (immediate) side-effects. I've actually started experimenting with an automatic compiler tool for Lithium, which would allow you to precompile your apps in a slightly more flexible way. The concern is that as your application grows, you might end up including a ton of classes where they might not always be necessary (ergo wasting memory), so we've come up with a way to mitigate that. But yeah, your ultimate point is spot-on. Any reasonably flexible framework can be tweaked into oblivion if all you care about is performance, but in terms of actual application development, that might be the exact opposite of useful. The next step we're taking is to give people the tools analyze their applications and make some context-sensitive decisions about how to apply these kinds of optimizations, once you actually know a little about how your application runs.
Yeah, I think preloading is worth doing because it's a cheap performance gain. It is tricky to figure out how to manage it across many requests so you're not burning through memory, but I think even the simplest method of just compiling the most likely used classes even for the basic MVC cost of a request would work in a pinch. Will definitely be looking into getting something to do with preloading shipped with ZF 2.0 - worth doing right after we get rid of all the damn require_once calls stuck all over the place in 1.x
Code Igniter wasn't in the original benchmarks for Symfony 2 (which I "improved" in the article). No offence or anything intended, I know Code Igniter is lightening fast in similar benchmarks.
Its good to see that almost anyone can win in the benchmark speed race if they dedicate enough time to optimizing the key parts being tested.
Thanks for the entertaining and interesting post
Lies, damned lies and statistics! How we love them
My answer has always been that it isn't what you use, it's how you use it (easy now!) - that goes for frameworks, libraries and especially languages.
Although I agree with everything in your post, when frameworks start competing on speed, everybody wins. So I'm happy for the benchmark 'wars' to continue.
One thing I've always wondered about preloading - if you're using APC (configured correctly), do you still see much benefit from preloading classes, as aren't they all in memory anyway?
Preloading has a very significant impact on baseline speed, even with APC enabled. It may seem counterintuitive, but APC will still cache per file, so grouping all preloaded classes as a single contingent file is still faster.
@Tim
What is a correctly configured APC ? Standard-setups (apc.stat=1) for apc cache each file, but for EACH file included in an app apc has to check if the file has changed, means 200 class[or includes or requires] = 200 file-system-checks. So compiling everything into 1 file makes that 1 file-system check (while having apc.stat=1). For using apc.stat=0 you need to use absolute pathes for each include/require and if you change code and want it to be recognized, you need to restart the webserver or have a script which deletes changed files from apcs cache.
By 'correctly configured' I meant with stat = 0
I take your point on absolute paths. In the context of ZF (assuming all of the require_once calls have been stripped out), I'm thinking more in terms of autoloading. I guess if the class has already been preloaded then the need for autoloading is removed, so I've answered my own question.
Not to forget the ZF-Autoloader uses the include-path and therefor no absolute pathes, means stat=0 + ZF-Autoloader is still at least 1 filesystem-check / file.
Using stat=0 would need rewriting the ZF-Autoloader and assigning absolute pathes to prefixes.
So great, i've been waiting for you to post this for while! It would definitely be nice if frameworks started showing users HOW they optimized the framework for the benchmarks instead of just saying "ha! we r teh best!".
why do we forget that benchmarking performance of a framework is not the only factor - there are others. if any one doesn't know, well ... no comment.
although, they only thing we should keep in mind that the framework shouldn't be really slow - and that's that cheers !
You have left our quite an important detail: Which Battlestar Galactica theme is one supposed to play before running the benchmarks? The classic one or the modern one? This is important when making the next reference to Fabien Potencier dressing up as a Cylon, because now I don't know whether to imagine him with a blonde wig and a skin-tight red dress (which is rather disturbing...), or a metal armor with a Knight-Rider-ish sensor light in the helmet (less disturbing and probably funny when he bumps into stuff because he can't see shit).
Regarding the music choices, try death metal - I've once seen a Mythbusters episode where plants subjected to death metal actually grew faster than those "hearing" classic music. Aside from these points, great article and the quality irish eloquence I've come to expect and love
Anyone who has profiled a real application (not these bullshit benchmark applications) will know that the application-specific code is always the slowest part, not the framework itself.
Anyone who wants to improve the speed of their app should look at improving their own code first, you can make much bigger gains.
But...but...benchmarks are more entertaining!
This post made me laugh - especially Paul M Jones' first comment: "I can't tell if you think I'm an ass, or if you're just being over-the-top."
lol - very entertaining post.
Really entertaining post! Congrats for demonstrating that ZF is in fact the fastest framework around... I'm glad as Symfony 2 actually uses some ZF libraries
For the record, Symfony is not the only framework to pack core classes in one big file to improve performance. And if Lithium, ZF, and some other frameworks use the same technique to improve their speed, that's great news for me. Also, even if I like your hilarious demonstration a lot, I think optimizing a framework for the default configuration is what it is really about. Most people will only ever use the default configuration, without any performance tweak. If you read carefully the methodology of my benchmarks, you will also find out that I'm trying to measure the speed of the full-stack frameworks, with everything "enabled", not a framework optimized for a "Hello World" app, which is of course a plain non-sense. To conclude, I like to say that most frameworks out there are fast enough for most applications.
Thanks for dropping by Fabien. Great work on Symfony 2! Not to detract from Symfony 2's achievements, I suppose my own point was a little more selfish in terms of the ZF suffering performance hits from 4 extremely obvious sources. It will be interesting to see how my inevitable performance post about the planned Zend Framework 2.0 is received
I'm a big fan of Symfony 2 as well, but I'm also curious as to how Zend Framework 2.0 will turn out! Thanks for the benchmarks Pádraic
I don't understand your point. You are basically saying that when you take away parts of the framework that the framework is faster. So why not try and optimize the framework for the default settings? What about caching pages? What's the point of having components like Zend_Application_Bootstrap if it only adds bulk? Does the convenience added justify the bulk is the real question? Maybe for some people it does. It just seems very odd to me to strip away parts that are there by default, why not focus on making the parts that are there faster?
I am using ZF 1.10.1 for a fairly big project right now, and what I am looking into is how I can use caching to speed everything up. I think that if you ask developers if they would prefer a framework that strips away parts that are supposed to make it easier to use, not many would want to use it, so that's why I think that when people start to add components or begin design a framework in the first place they should be thinking: is this the most efficient way to do it?
The point was simply that there is no point
There's lies, faster lies and benchmarks!
Amen to the article.. This shows never ti trust benchmarks alone, but to look for ease of use and required features more.
it test is not objective because i cant' see the code which you tested
http://github.com/padraic/framework-benchs
Completely useless demonstration... The point of using a framework is to minimize the time needed to create a working application. And the goal isn't to strip out the functionality or search for a better solution. Maybe I will write my own framework from the scratch it will be much much faster
Did I not just say benchmarks are useless already? Dude, you need to put your sarcasm hat on!
What I wanted to say Dude: your demonstration doesn't apply in any way to the symfony benchmark that's all. Maybe you would read carefully the whole benchmark. The benchmark is showing us few things about the symfony 2.0:
a) It will be highly and easily configurable. Hell look at "learn more" examples. b) It will be fast and in terms fast I mean fully featured with nice boost in performance. c) We can say it extends a), you can simply create "micro frameworks" I will not argue which framework is better I have a close friend who is creating projects with ZF and he likes it, I never understood people who used ZF in the first place but every framework have his good an bad sites and which framework you choose it solely depends on what you need and expect. From my point of view the power of symfony framework isn't the whole speed factor, of course it is important but most important is very good documentation and adapting some of the best programming behaviors.
You need to read the article again, I'm not criticising Symfony 2 in any way, shape or form. In fact, I compliment Fabien's impressive work on speeding it up. The benchmark was merely to highlight that speed is relative, and doesn't have all that much relevance to picking any framework. As to features, no comment. Most framework differences lie in the VC integration and a surprising amount of those differences are more about feature wealth and development style than anything else.
Hi Padráic,
Do you have a practical example of stopping using the ViewRenderer? I've been playing a bit with it, but as I also use Zend_Layout I can't get it OK. I guess that's because Zend_Layout and the View_Renderer probably work in a very "coordinated" fashion. Anyway, I've been just measuring and just using your custom preload function and using preload I see a performance gain of over 25% (in my own case, I mean) And just in case it helps, there's a very easy way of getting the whole list of class container files to add to the preload file; just add the following temporary modification: function autoload($class) { require_once str_replace('_', '/', $class).'.php'; $log = @fopen('autoload.log', 'a', false); @fwrite($log, 'Loading file: '.str_replace('_', '/', $class).'.php'.PHP_EOL); fclose($log); } spl_autoload_register('autoload');
I don't use Zend_Layout either, but don't tell anyone
Hi there!
Small correction: After some tweeking here and some playing there, the performance gain I see is of over 50%. That's a huge gain, so thanks for sharing your benchmarking knowledge. By the way: Will it be possible to have some comments from you (obviously when you have a time slot in your busy agenda) about how to stop the ViewRenderer when Zend_Layout is used? It would be great. Thanks!
Hi,
I'm also interested in speeding up the overall view rendering, be it with or without Zend_Layout. I would greatly appreciate any hints, links and general pointers. Thanks,
Dear Sir, it is nice to see the benchmark war continue since as you say "My fellow Zend Frameworkers, we cannot allow this to stand".
I think it is time a completely independent group is created and starts benchmarking Frameworks on the SAME machine(s). Good report, you seem to have spent some time presenting all this information, but as I am always skeptical I have to mention that in my opinion the Zend Framework is slow. If someone wants a reliable, "fast" deployment of the Zend Framework then i think he should consider the stack offered by Zend (= Zend Server + Zend Framework). Thank you for the interesting findings. Regards,
This sounds like it could be a new website idea. Issue a challenge to developers to complete a basic website with specific functionality. Allow them to optimise all they want. Then rank them on how much non-framework code, speed etc.
Benchmarks fail as they can not measure what a developer can do. A developer competition with perhaps a prize would measure frameworks when they are used properly. |
Calendar
QuicksearchCommentsJohn W. about PHP Framework Benchmarks: Entertaining But Ultimately Useless Fri, 05.03.2010 23:39 I'm a big fan of Symfony 2 as well, but I'm also curious as to how Zend Framework 2.0 will turn out! Thanks for th [...] Mikael Gramont about PHP Framework Benchmarks: Entertaining But Ultimately Useless Thu, 04.03.2010 17:34 Hi, I'm also interested in speeding up the overall view r endering, be it with or withou t Zend_Layout. I woul [...] Moaner about PHP Framework Benchmarks: Entertaining But Ultimately Useless Thu, 04.03.2010 07:36 This sounds like it could be a new website idea. Issue a cha llenge to developers to comple te a basic website with [...] Carlos Aguado about PHP Framework Benchmarks: Entertaining But Ultimately Useless Wed, 03.03.2010 06:51 Hi there! Small correction: After some tweeking here and some playing there, the perfor mance gain I see is of o [...] andreas about PHP Framework Benchmarks: Entertaining But Ultimately Useless Tue, 02.03.2010 17:21 Dear Sir, it is nice to see th e benchmark war continue since as you say "My fellow Zend Fr ameworkers, we cannot al [...] Pádraic Brady about PHP Framework Benchmarks: Entertaining But Ultimately Useless Sat, 27.02.2010 22:24 I don't use Zend_Layout either , but don't tell anyone Carlos Aguado about PHP Framework Benchmarks: Entertaining But Ultimately Useless Sat, 27.02.2010 16:51 Hi Padráic, Do you have a p ractical example of stopping u sing the ViewRenderer? I've be en playing a bit with it [...] chrisweb about PHP Framework Benchmarks: Entertaining But Ultimately Useless Fri, 26.02.2010 21:11 Padráic your the man Pádraic Brady about PHP Framework Benchmarks: Entertaining But Ultimately Useless Fri, 26.02.2010 18:32 You need to read the article a gain, I'm not criticising Symf ony 2 in any way, shape or for m. In fact, I compliment [...] maker about PHP Framework Benchmarks: Entertaining But Ultimately Useless Fri, 26.02.2010 17:52 What I wanted to say Dude: you r demonstration doesn't apply in any way to the symfony benc hmark that's all. Maybe [...] екаранный бабай about PHP Framework Benchmarks: Entertaining But Ultimately Useless Fri, 26.02.2010 16:58 Ну хоть по русски кто-нибудь ч то-нибудь написал( Pádraic Brady about PHP Framework Benchmarks: Entertaining But Ultimately Useless Fri, 26.02.2010 03:06 Did I not just say benchmarks are useless already? Dude, you need to put your sarcasm hat on! Eriksen Costa about PHP Framework Benchmarks: Entertaining But Ultimately Useless Fri, 26.02.2010 01:07 Padráic is the new PHP terrori st. maker about PHP Framework Benchmarks: Entertaining But Ultimately Useless Thu, 25.02.2010 23:50 Completely useless demonstrati on... The point of using a fra mework is to minimize the time needed to create a work [...] Pádraic Brady about PHP Framework Benchmarks: Entertaining But Ultimately Useless Thu, 25.02.2010 22:51 http://github.com/padraic/fram ework-benchs CategoriesArchivesTop ReferrersShow tagged entries application security article astrum futura asynchronous processing atom bdd behavior-driven development behaviour-driven development book deep end dependency injection design patterns devnetwork docbook documentation eve online games htmlpurifier inversion of control irish php user group irishisms maugrim microformat mock objects model mutateme mutation testing mvc oauth openid openid and yadis pc gaming pear phing php php game development php games php general php security phpmock phpspec phpunit poka-yoke qgl quantum game library quantum star se rantings rss simpletest snarl solar empire surviving the deep end symfony tdd tutorial unit testing xp programming xrd xrds yadis yaml zend framework zf proposal zfstde |
|||||||||||||||||||||||||||||||||||||||||||||||||


