By David Peterson

Rasmus Lerdorf: PHP Frameworks? Think Again.

By David Peterson

This is the fist time I have heard Rasmus Lerdorf speak and it was entertaining to say the least. Refreshing would another way to describe it, I enjoy hearing real opinions and not holding back — Rasmus doesn’t hold back.

Just a short background, Rasmus Lerdorf is the creator of PHP and still continues as a core developer to the PHP project.

PHP frameworks

In his address he choose to highlight PHP frameworks (Drupal was not spared) and how poor they are at performance. Not only are they slow, but their "jack-of-all-trades" attitude leads developers down the wrong path by not using what is best for the job. He continues on by stating that PHP developers really need to think about performance for not only scalability reasons but for green reasons. If programs were more efficient it would cut the number of data centres and would reduce energy needs as a result. In our newly emerging age of energy awareness this does become an important aspect and I am glad that he is raising awareness.

Back to frameworks, he started by discussing a database heavy Twitter mashup that he created. This does a lot of database calls and a lot of behind the scenes work. By hand-tuning it he was able to get on the order of 280 req/sec. By comparison and simple HTML page with nothing but "Hello World" served by Apache is just over 600 req/sec. Okay, stage is set (by the way, this was tested on his local machine).

Hello World

How do PHP frameworks score on the "Hello World" test? No database calls, just the framework being used in its native tongue to output Hello World. The results were not too good, one of the fastest got just over 120 req/sec, the slowest was 8 req/sec. This is a dramatic difference and of course highlights his argument for performance. Where did Drupal score? Right above 50 req/sec. So not the greatest, but he did make the point that Drupal is not really a framework in the traditional sense. It is a web content management system that can be quickly extended.

So, are there any frameworks that don’t suck? Rasmus did mention that he liked CodeIgniter because it is faster, lighter and the least like a framework.

How to make PHP fast

"Well, you can’t" was his quick answer. PHP is simply not fast enough to scale to Yahoo levels. PHP was never meant for those sorts of tasks. "Any script based language is simply not fast enough". To get the speed that is necessary for truly massive web systems you have to use compiled C++ extensions to get true, scaleable architecture. That is what Yahoo does and so do many other PHP heavyweights.

RDF, Semantic Web and the Monkey

RDF in Drupal. Rasmus made a special point of highlighting the importance of embedding structured metadata into the page. RDFa allows you to embed data into your web pages and also lets you create custom vocabularies, or even better, reuse existing vocabularies. Why would you want to do this? Searchmonkey will go out and index this content and open up a rich search API to allow you to do intelligent queries. Well beyond what is possible with traditional search.

Along with rich search you also get enhanced search results. I have blogged about this previously so take a look. It is really cool stuff and I will be discussing it in much more detail over the course of the conference.

Pitching the Semantic Web

What if all Drupal sites had embedded RDFa tags? Well, for one, Yahoo would be very happy. It would play directly into the strengths of Yahoo’s new Semantic Web strategy. They are trying to do interesting things with semantic data but of course they need data — the classic chicken and egg thing.

Rasmus mentioned that Yahoo’s semantic data store can scale to the size of the web so the invitation is open.

The future of Drupal

This is where my focus at Drupalcon is, driving the adoption of semantic technologies within Drupal — I feel that the momentum here will make that a reality. There is a lot of interest, a Semantic Web BoF session was stacked with people with some cool ideas…

More to come.

  • pcdinh

    CI is fast. Yes. But I don’t like CodeIgniter because its architecture is so simple and immature that I think it is written by developers who are new to OOP and design patterns. Besides, I found that CodeIgniter coding convention is not compliant with PHP Coding Standard. However, PHP community in general is not good at OOP so CI is good enough.

    But the question is how fast is fast enough? Is premature optimization all about?

  • Pingback: Tobias Schlitt - a passion for php()

  • Pingback: CI gets a pat on the back | Chris Monnat()

  • Anonymous

  • caillou

    i think you didn’t understand what rasmus was saying … i even think you did not listen to it … or maybe you are a bit to slow to listen to him ;)

  • Rasmus

    Just to clarify on the “PHP isn’t fast enough” point there. What I said was that PHP (and every other scripting language) alone isn’t fast enough for someone like Yahoo. We have to do some of the heavy lifting in C or C++. Imagine a search backend written entirely in a scripting language. It just doesn’t work. PHP is plenty fast enough for the frontend data marshalling tasks, but heavy-duty algorithmic backend processing is better left to a strictly typed compiled language like C++.

  • Anonymous

    You forgot to mention whether Drupal or any of the other frameworks, for that mattter were using built-in caching (as Drupal does) or op-code caches like eAccelerator.

  • Anonymous

    You forgot to mention whether Drupal, WordPress or any of the other frameworks were using op-code caches like eAccelerator or had built-in caching enabled (as most Drupal do).

  • Pingback: WAZ (weblog andre zorzo) » Rasmus Lerdorf e PHP Frameworks()

  • Pingback: SitePoint PHP Blog: Rasmus Lerdorf - PHP frameworks? Think again. | Development Blog With Code Updates :

  • Mark

    1. It all starts with “I don’t need a framework.”
    2. Then you create 7 classes.
    3. Now you have a small library of classes.
    4. Then you create an application that uses your library.
    5. It works and it’s fast, hurray!
    6. Then someone asks you to extend the functionality of your application.
    7. And they keep asking for more, and more, and more and more…
    8. Now you have 43 classes.
    9. You’ve learn so much in the last 2 years. Design patterns, security, performance, testing…
    10. What once was a small library is now a big, ugly, un-tested, un-documented, scary framework.
    11. Then you change jobs.
    12. And you create another 7 classes…

    This has been happening for the last 30 years.

  • Pingback: Rasmus Lerdorf - PHP frameworks? Think again()

  • asnyder

    Rasmus should check out NOLOH (Not One Line of HTML),, we think he’d like it. NOLOH is lightweight, on-demand, scalable, and significantly faster and more feature rich than something like codeigniter.

    Dan Shafer, a respected technologist has this to say:

  • Aaron Greenspan

    Equating the presence of any framework with poor performance isn’t a logical thing to do. I wrote a PHP framework, refused to add anything I didn’t absolutely need, and it performs just fine. (It’s also entirely procedural; there are no objects.) For anyone who’s interested, it can be found at:


  • Pingback: Web 2.0 Announcer()

  • It’s the same old story… The “Hello world” test is pretty irrelevant. What about testing a database driven web site that requires a new funcionality very often? Even if you don’t want to use a 3-rd party framework, you have to write your own. Therefore, you should consider if you will be more productive with your own framework, if your own framework will have a necessary level of extensibility and if your own framework will lead to a better performance. Perhaps, you don’t need to reinvented the wheel, but use a framework.

  • Tom

    Ok, you lost me on the “Green Reasons”. That demonstrates unbelievably stupid perspective.

    But it another way… turning your air condition off for one day will save more electricity than if you spent a year rewriting all your php code in C.

  • Pingback: Web 2.0 Việt Nam » Blog Archive » Lập trình viên đang góp phần tàn phá môi trường?()

  • Ivor

    What Rasmus is saying is that, PHP, unlike other scripting languages, gives you the option to build fast web applications without the need of using a framework. Ruby and Python, for example, depend on specific frameworks, PHP doesn’t. Facebook, Wikipedia, WordPress and other huge sites don’t use Rails, Django or Symfony. They use what is best for the job. That’s a luxury that only PHP has.

    BTW, if you want to reduce energy consumption, stop global warming and save the planet, you can also turn off your TV, start writing letters instead of emails, and downgrade to Windows 95. Yes Windows Vista requires 30 times the computing power to operate at a performance level similar to that of Windows 95.

  • I can see how this makes sense for huge websites like yahoo but for the majority of sites a plain old PHP framework should work just fine.

  • Brian

    asnyder, visit a NOLOH page with JavaScript turned off. It will send stuff back to search engines to munge on, but it won’t do that for a user.

  • asnyder

    Brian, the current stable version of NOLOH requires JavaScript to to be enabled for users, but not for search engines, the next update includes significant changes that allow for NOLOH websites/applications to work properly with JavaScript disabled. Thanks for your comment.

  • Arkh

    Ouch, I stopped here :
    Maybe advertising to webdevs (which I think is a population having the more noscript users) isn’t a good thing if your own homepage is broken.

  • Brian

    I knew the bit about search engines. It’s good to know that they are working on making it work without JavaScript as well. I wouldn’t be able to use it otherwise.

  • asnyder

    Arkh, in a previous post we mentioned the upcoming version which will allow for NOLOH applications to fail gracefully without JavaScript. However, you’ll notice the page you landed on asked you to enable JavaScript for it to function properly, I don’t know how you can categorize that as broken. Furthermore, in today’s current web environment more and more applications use AJAX related technologies, and require JavaScript to be enabled, but we do understand that certain developers like to play the JavaScript disabled argument, which was the primary motivation behind the upcoming fail gracefully update.

  • Robert

    @asnyder, i have two points for you…

    first: you need to try to access your page with NoScript running. Usually, visiting a page which has javascript will cause a small popup to give the user teh option to allow the page. By redirecting to another, javascript-less page, you force the user to manually add, which is a pain in the rear

    second: I don’t know if there have been advancements in screen reader technology, but from what I know, most do not work with javascript yet. By requiring javascript, you are blocking access to these users.

  • asnyder


    I addressed your first statement in a previous post. In regard to your question about accessibilty please see our response to a similar inquiry from a university at

    Thank you for you feedback.

  • Arkh

    Asnyder, when testing a new site I tend to react like the 2s-attention-span user : if it works, it’s good. If I have anything to do (like enabling js) before seeing something which may hook me, I close the tab.

  • Haven’t had a chance to surface yet (in Singapore on my way home) from travelling but I will respond to comments when I arrive back in Oz.

    Thanks all for the great discussions…

  • Eduardo Marinho

    Agreed. Let’s disregard standardization and reinvent the wheel everytime. While we’re at it, let’s scrap all other languages and program everything in C (without any libraries), for performance. After all, the computers are our masters: we work hard and waste our time so they can lay on a hammock, relax and drink coconut water.

  • igmuska

    After watching Lerdorf’s long Drupalcon video, he gave me the impression that the days of php frameworks are numbered although they are meant for people with little or no php coding experience. In other words, the user’s purpose should drive web development and not coder. There are many php frameworks out there but little that offer more than words about how much more greater, how much more usable, their framework is over their competitors.
    The main impression though I felt after reading some unknown coding author write about how he feels that it might be better to let the web to do the work through plugging API widgets into his client’s sparsely coded website.
    Then while watching Lerdorf respond to questions about optimizing Drupal for speed, he answered that interpreted languages will always be slow…then enlightenment came over, waking from hearing the words I wanted to hear. Now I know handing coding simple CSS pages are the best…YAY Sitepoint!

  • Pingback: Andrea Grandi » Blog Archive » Dieci buoni motivi per non utilizzare PHP()

  • Pingback: Coderies du jour |

  • Pingback: Coderies du jour |

  • Pingback: CSS Layouts Vs. Table Layouts (which is better?) - Webmaster Forum()

  • firebus

    from my perspective, the big win from using a framework or CMS is security.

    drupal has a great security team, frequent updates, etc.

    if i write my own system from scratch, and install various versions of it on various client sites, then when someone finds a vulnerability my life sucks.

    with drupal, i just update.

    rasmus may be smart enough to write secure web applications from scratch in PHP, i am not! i’ll take the performance hit, and the shackles, in exchange for a mature, secure, framework with many eyes looking for bugs.

  • Doug Putnam

    Listen to Rasmus. Rasmus is a breath of fresh air in this Ruby on Rails/cakePHP/Django crazy world.

    These generic frameworks are really crack for programmers — you see an MVC evangelist create a blog in 5 minutes, and you’re hooked! Try to use Rais/cakePHP/Django for a practical project, though, and the first thing you do is ditch that Active Record class because is like dragging an anchor dragging behind you. These frameworks may be clever programming but I say, use the good parts and ditch the rest.

  • Pingback: Jason Leveille’s Blog » Blog Archive » Blog Overhaul Using Django()

  • Pingback: PHP Frameworks and Scaling | No Droids Allowed()

  • Pingback: Bienvenidos — Santiago Borrazás()

  • Pingback: Blogelse » Choix d’un framework Php()

  • Nathan

    This site always uses misleading titles. The article mentioned one framework and talked about drupal (which isn’t even a php framework). What a waste of time.

  • Pingback: CodeIgniter’da Kütüphane Yazmak()

  • Pingback: CodeIgniter’da Kütüphane Yazmak()

  • Pingback: CakePHP vs Django vs Rails vs Who Cares - Make a Decision « Jason Leveille’s Blog()

  • Christian

    Hello David,

    thank you for the article so much. I was glad to hear, that I am not the only person on this planet, that thinks that performance is one of the major features of a framework. Recently we re-performed a RPS benchmark and it is in fact surpising, how many frameworks have bad performance. On you can see some of the results and an analysis of the test.

    Personally, I think, that developers still believe caches to be the only way to make things fast. But as you – well rasmus – mentioned in the article, this is neither green nore a good scaling base for your infrastructure.


  • Pingback: Nice video shows how hidden structured data from the Drupal content management system can lead to semantic search « Cloudlands()

  • Anonymous

    First, The article has a total misleading title. what has slowness of Drupal got to do with slowness of PHP? I can write a bad program in any language I want. That is the easy part!

    And can someone explain

    1) How we can have a 8/second to 120/second variance for a simple hello world program
    2) How can a Drupal page at 50 REQ/second score better than plain vanilla hello world program at 8 REQ/second?

    its really amazing that so many people are blindly quoting from this article.

Get the latest in Front-end, once a week, for free.