Which PHP Framework is the fastest?

Tuesday, June 5th, 2012|Uncategorized|by Romans

This question is often asked, but is never answered properly. So how to measure framework speed? Let me also explain why “scalability” is more important than general “performance”.
The primary goal of Frameworks and Libraries is to make certain things simpler and easier for developers. Frameworks can also be categorized by what it is they’re simplifying:

  • MVC Frameworks help you organize flexible page structure
  • Database frameworks (also called ORM) help you to organize flexible database access interface
  • User Interface frameworks will help you make your user interface consistent
  • Security frameworks will help you introduce security practices in your software.

Frameworks do that by introducing some assumptions, generalizing and also restricting developer to certain practices which framework authors approve of.

It’s fairly obvious to anyone than adding thousands of lines of code to your  ”Hello World” application wouldn’t make it execute faster. The regular argument of a framework authors is that they help development process to be faster and smoother on a larger projects. This often nothing to do with the speed of the code execution: “Developer time is more expensive than CPU time”.

What’s worse is that some frameworks impose standards which slow your code down. An example is a basic Acitve Record implementation, which brings your powerful SQL engine to the level of Simple DB to match the lowest common feature denominator across multiple database vendors. This along with a general overheads of the framework greatly contributes to the “slowness” of your project.

So how can framework contribute to performance of your project?

1. Make Fewer SQL Queries

When your frameworks sends request to a database and waits for result, it introduces latency. The PHP code waits for data to be parsed and executed by SQL and results to be returned. Because today SQL is still the most popular way then your job is to make as little queries as possible. If you could build your page with 10 SQL queries instead of 50, that would speed things up a lot.

Having less number of queries means each query would be more complex and would retrieve more data. Yet we don’t want to write the queries. Your database framework will have to have concept of expressions, joins and sub-selects to be able to off-load as much logic as possible into SQL engine. If number of queries on your page increases along with number of records displayed on the page, then you have produced non-scalable code. If your framework endorses this practice, then your framework is not scalable.

2. Selective render

When you look at the page such as this one you see many different areas with many different types of dynamic data. As it happens with dynamic web pages, some areas of your screen will refresh themselves. There are two approaches to do so

  1. Build a separate JSON service for sending updates
  2. Let framework handle the refresh

The (2) is very tempting, but average frameworks can’t perform web page refreshes graciously, that’s why many developers will have to duplicate some code and build a separate mechanism for JSON polling. This introduces inconsistence and bugs in the user interface. Many developers resort ONLY to JSON polling after the page is loaded increasing number of dynamic requests, making page unusable for search engines, building reliance on javascript and severely reducing total page load time.

For a scalable framework it’s an absolute necessity that the fragment of the page could be inexpensively re-rendered and reloaded with as little database traffic as possible and without additional coding from developer.

3. Parallelization

Suppose you have two different API services behind your web frontend. One service is built to return JSON with list of on-line users. The other service returns the JSON with recent post feed. Your frontend is written in your favorite PHP framework which makes use of templates or some page logic to determine if any of those page areas (or both) needs displaying.

JSON backend introduce some serious latency in your request, so it’s imperative that you your frontend PHP framework would execute both requests in parallel. Unfortunately most of the PHP frameworks want the data pretty much right away, when the page is rendered.

A scalable framework would be capable of identifying which widgets you need to display on your page and allow to execute both JSON requests first before collecting their output.

4. Overheads

Minimization of overheads is often the ONLY practice frameworks concern themselves with. This is where modularity is important. Let’s say the developer X have built a plug-in for WordPress. He decided to use super-fast framework and throughly benchmarked his add-on. Next comes the developer Y who have also built a plug-in for WordPress with a different framework but equally as fast. WordPress now requires to initialize two frameworks introducing huge overheads.

You might have been seen this in practice with a different set of frameworks, such as Zend and CodeIgniter. And then you integrate Facebook API which does not rely on any framework and makes you chew through thousands of line of PHP code which you don’t need anyway. And you also use ORM of your choice which has no dependencies yet re-implements tons of code.

A scalable framework should provide a unified set of modules and practices which are used by all of the plug-ins and add-ons to avoid any code duplication. In practice, decoupled frameworks are very bad for scalability. How many frameworks would provide add-on developer with a consistent API for building user interface?

5. Caching

After making all the possible mistakes in the book, frameworks do implement a caching strategy and brand themselves as a “High Performance”. The caching is not a cure and will introduce complications and limitations. Framework must be fast and scalable without any caching. Yet caching is important too. There are two types of caches: data cache and output cache.

The data cache helps developer to skip some database queries. If your implementation requires you to traverse models on each row (such as to determine URL for user thumbnails), then adding a memcache seems like a good-enough solution to the problem. This does help scalability a little, but essentially displays outdated data and can lead into many nasty problems.

Output caching helps you to cache either parts of the page or all the page completely. Many MVC frameworks wouldn’t have sufficient support for implementing output caching, because they are used to “echo” things out. As developer it becomes your burden to collect output into buffer and build logic for substitution and keeping cache up-to-date.

A scalable framework should handle both tasks flexibly and consistently. It should allow you to exchange your expensive data source (SQL, JSON) with a faster data source such as Memcache gracefully and transparently.

The framework should be equally good at letting you substitute whole areas of the page with a static alternatives without loosing functionality and requiring you to go under the hood of page routing or loosing any dynamic functionality on your page.


Many PHP frameworks sucks at properly understanding scalability principles. Look into a Silex framework and imagine that your project has 200 pages. On every page request, it will execute 200 matching pattern checks which are NOT based on regular expression. How is that scalable? Possibly another caching would help?

I am saddened by the state in which PHP frameworks are today and I believe there are many things which can be improved. I also believe that developers can be educated to have a good judgement and understanding of scalability.

There is huge potential for the next generation of PHP frameworks and I strongly encourage you to write and talk about it.

So should someone ask you, “what PHP framework is the fastest” — tell them that they are all slow, but some of them are “scalable”.

I have implemented all of the scalability principles described above in my framework: http://agiletoolkit.org/ but if you have a worthy alternative be sure to leave a comment with some clarifications.


Damian Tylczyński
Posted June 7, 20126:27 pm

“Look into a Silex framework and imagine that your project has 200 pages. On every page request, it will execute 200 matching pattern checks which are NOT based on regular expression. How is that scalable?”

It’s funny what you are saying. Do you believe that there is any URL routing system that will not check every route before choosing one? Do you think that routing systems are “guessing” what route to choose or they are choosing the route randomly?

Phil Sturgeon
Posted June 7, 20126:56 pm

Good point, every single website built with a framework is going to instantly explode as soon as anybody uses it. We should all delete our websites before they crash and use your product instead.

Thank you for bringing this startling discovery to our attention. I will suggest that EllisLab delete CodeIgniter, and tell the FuelPHP team not to bother anymore.

I wish I thought of this earlier. You are a hero.

Jani Hartikainen
Posted June 7, 201211:37 pm

Overall a pretty okay overview of some techniques for improving performance. I may be nitpicking a bit, but some of the following points did bother me a bit:

I don’t really see what #3 has to do with PHP. Although parallelization is a valid strategy to improve performance, you’re talking about JavaScript code, not PHP.

You say “This is where modularity is important” in your example about reducing overhead. Yet, you then proceed to say “decoupled frameworks are very bad for scalability”. Modularity introduces decoupling, so isn’t that a contradiction?

You gave Zend Framework as an example here about overhead. I have personally used ZF in a variety of projects, along with other large libraries such as Doctrine 2 (or the Facebook API), and in my experience the time it takes to load the necessary code is insignificant, even more so when using bytecode caching.

As you suggested your ATK framework, I attempted to look into it a bit. However, I find that much of the documentation does not exist (or at least the links are broken). I tried looking at the code on GitHub to get a handle on things, but it’s not exactly helping much.

As important as performance can be, I believe having good documentation is very important as well.

Posted June 7, 201211:52 pm

Approve Phil Sturgeon’s comment.

Posted June 8, 20125:57 am

Why in hell would you use silex as an example in your conclusion. It’s a microframework where you need to take care. As for routing, there are ways to get your dynamic routing into hardcoded apache rewrite rules automatically, so the framework doesn’t have to care at all. Or you could use symfony2, which is a full-stack-framework and takes care of fast routing.

Stelian Mocanita
Posted June 8, 20126:34 am

Even though I do feel your pain and agree with most parts of the article, the Silex part is over the line. First of all, you actually pick on the framework vowed to be a “micro-framework”. Secondly, does it matter how much Fabien is charging a day?

In future articles, I would refrain from direct personal attacks and stick to the tech side, as that one was a good read and made valid points.

Posted June 8, 20123:01 pm

@Damian: Certainly. If part of the URL correspond to a file name and follows a rule of using slashes, it can be easily mapped. The rest of the URL can then be mapped into variables if developer desires that. Creating complex routing schemes only makes projects messier.

@Phil: I love variety of frameworks, but authors must put more thought behind them.

@Jani: Zend framework is anything but lightweight, especially if you use it as a “framework”. With PHP you need a framework which does things quick. I’ve wrote this comparison some time ago, but I think it still valid: http://demo.atk4.com/demo.html?t=17. Please follow updates, more documentation is coming.

@Stelian: Thanks, I’ve amended the article.

Phil Sturgeon
Posted June 8, 20124:04 pm

You asked me to be more constructive over twitter, so here are my thoughts in full.

1. Make Fewer SQL Queries

This is nothing to do with the framework, this is to do with the developer. If I am using native PHP with the mysqli_query() methods and write 50 queries instead of 10 then it will be slower. What point are you trying to make?

2. Selective render

Using AJAX to syncronise page information is of course quicker than loading an entire page, this comes down to HTML and browser rendering and is irrelevant of the framework being used. If you create your entire website in just PHP then it will be slower than a smartly written AJAX-enabled application.

If you re-develop the entire frontend in JavaScript it will be shiploads quicker, especially if you use BackboneJS and just have the PHP framework creating an API then your application will be blazingly fast – but this is not something your toolkit will do any differently to a PHP framework.


3. Parallelization

Yes, loading things can be slow. Loading less things will be quicker. Congratulations.

4. Overheads

You say this:

“This along with a general overheads of the framework greatly contributes to the “slowness” of your project.”


“Minimization of overheads is often the ONLY practice frameworks concern themselves with.”

So, what?

Then this statement confuses the hell out of me:

“Let’s say the developer X have built a plug-in for WordPress. He decided to use super-fast framework and throughly benchmarked his add-on. Next comes the developer Y who have also built a plug-in for WordPress with a different framework but equally as fast. WordPress now requires to initialize two frameworks introducing huge overheads.”

Who is building WordPress plugins with frameworks? Are you trying to suggest that frameworks are a bad idea because people are integrating two frameworks into a CMS? That makes litterally no sense to me in any way. If a developer is doing that they need to have a think about their career.

“And then you integrate Facebook API which does not rely on any framework”

No API relies on a framework. Do you understand what an API is?

“[continued]… makes you chew through thousands of line of PHP code which you don’t need anyway.”

Well you need those lines of code if you’d like to interact with the Facebook API easily. Or you could write it yourself with file_get_contents() but you’ll have a hard time authenticating your user with OAuth without creating roughtly the same number of lines in your application that the Facebook SDK would be adding in the first place. Either way, this is nothing to do with a framework.

“A scalable framework should provide a unified set of modules and practices which are used by all of the plug-ins and add-ons to avoid any code duplication.”

You just described PSR-0, which your framework does not support. Plenty of others do though, like Zend, Symfony and soon FuelPHP. You should look into that.

5. Caching

Agreed, not caching things can be slow. Point well made.

MY Conclusion

Your entire article says that whenever you do anything it is slower than doing something. You have failed to answer the title of your blog post, which is almost impossible to answer anyway.

You suggest that your non-framework framework is faster than everything else, but offer no explanations as to how.

This entire article was just FUD written by the author of a basic collection of PHP classes who wanted to make a name for himself by saying every other framework “sucks”. I would LOVE to know why and you and your small team are smarter than the collective minds behind existing frameworks, many of which have been around for 6+ years and have had thousands of contributors.

Every complaint about a PHP framework is equally valid when applied to your Toolkit. Your Database Query builder is slower than plain SQL for example.

If you are so concerned about micro-optimization then write all of your applications in C instead of using PHP in the first place.

Final thought, which websites have you built with this Toolkit that maintain an extremely high load? I don’t see anything relevant in your portfolio that could back the claim that your system has scaled extremely well.

Posted June 8, 20125:10 pm


1. Writing SQL queries is inconsistent and is a recipe for disaster. When you do, however, you can optimize your queries. If you wish to avoid writing them, then it’s down to ORM. Your ORM might be limiting you though. Users want joins for performance, for example: http://fuelphp.com/forums/topics/view/8522. Most ORMs don’t handle Joins well. In Agile Toolkit ORM provides full support and interface for Join, Subselect and Expression objects. It is also fully integrated with Models and UI. As a result: 1) all queries are highly optimized. 2) developer don’t write SQL code directly, 3) there is consistency and it’s prone to human error. Do you know a mainstream ORM like that? Would you welcome a new great ORM? I would.

2. Most of the frameworks with few exceptions have no idea what happens in Smarty and what is being sent to the user. I’m talking about HTML here. Therefore a typical framework wouldn’t be able to produce a partial HTML. Unless developer specifically builds in a functionality to produce a partial HTML or even create JSON and back it up with JavaScript method, majority of the frameworks wouldn’t do anything. Again this is a source of inconsistency and increased requirements to developers, more code, more bugs. The JavaScript UI frameworks (like Sencha, etc) are good at refreshing themselves on demand, but if you ask me which PHP framework does that – I know only Agile and NOLOH. Then again – some others do, but have no universal method for user widgets.

So, how do you write real-time web app in Agile Toolkit? It’s already realtime.

3. Parallelization
You’ve missed the point here. The framework can be capable of understanding, which parts of the page needs to be displayed. Then, even though two different areas on the page might be produced by two different data sources and would be developed by two different developers with no knowledge of each-other, framework could initiate simultaneous requests to both data sources. Show me a low level implementation of this in CodeIgniter.

4. You should view frameworks as a broader concept. Framework might have very little code. Framework might not even have any code at all. Of course you can build a wordpress add-on with a framework of your choice.

But when add-ons take advantage of a rich feature-set of a framework, when an add-on can rely on presence of certain modules and a well organized core, then writing add-ons is easier and more fun. It goes so far beyond PSR-0. Why did you mention it anyway?

Re: Conclusion
It’s silly of you to come up with this. The point I’m making is the following:
– Writing everything yourself will give you fast code, lots of bugs, lots of inconsistency, and lots of custom code.
– Relying on framework X will give you slower code, but you write less, more consistently and with less bugs.

The trade-off between how much you write and how much you loose in performance is a framework scalability. I’ve outlined some major scalability concerns which Frameworks SHOULD address in my opinion.

I’ve also stated that I have implemented them in Agile Toolkit which is a major and serious product with commercial backing and impressive user base. However I welcome others to work on a solution addressing scalability on a framework level.

I agree that Agile Toolkit needs more polishing especially in Documentation and Examples, but it has been published a little more than a year ago and kept low profile, so for many it is still a very young framework.

As for me – I highly appreciate any frameworks with fresh ideas not just “based on ideas of other frameworks”. I am appreciative of people coming up with great concepts and making concepts simple to understand and learn. I look forward to any work which makes life of developer simpler.

Phil Sturgeon
Posted June 8, 20127:46 pm

We must be on crossed wires. After reading your article and comments multiple times I still have no idea what your point is.

Frameworks are bad because they add overhead, and they are also bad because they do not do enough?

So all frameworks are bad at doing everything, and your framework is good at everything. Is that it?

I’m signing out of the conversation at this point. Your attempts to make your product and company look better than every other established framework are completely laughable.

Posted June 8, 20129:15 pm

I tried to refrain myself from commenting any further, but now I am as amazed as Phil is. Just to be clear, I would like to say that I only know Phil from his dedication to the CI community (kudos for that btw ) and I am no fan-boy of Fuel, hell I only used it once.

Now, the article touches some valid points, that I am sure everyone got, beyond the inconsistencies. On the other hands, your comments and your reaction are just out of line. First of all, your framework is a baby compared to the “slower” ones and like it or not, everything your framework is or wants to be is a result of all those limited software architects behind Zend, Symfony and CI, their revolutionary approaches at the time being, their mistake, their bugs and their fixes.

Now, let’s talk agile toolkit. The first page I opened was http://agiletoolkit.org/doc/dsql where I had a code sampple on how things roll. As a free piece of advice, if your example uses unfiltered input straight into queries(->where(‘id’,$_GET['id'])), any decent developer would close the window and head-on to the next “slow” framework. I do not care if somewhere deep in the code jungle there is a filter_var working, that’s just bad to start with.

You praised the database abstraction layer that you have behind it, so I went further. How do I use a different database driver? I mean surely such a cutting edge architect would consider at least a nosql database, right? Moving on, I went to github to get faster and smarter, and yet what I saw was again dissapointing. The code in your relation lib(https://github.com/atk4/atk4/blob/master/lib/SQL/Relation.php) has absolutely 0 usable comments, so I had to start reading the code: $this->dsql=$this->owner->_dsql()->dsql()->table($this->f1); ( line 95 ). There is no human that can make sense of that without going in to actually debug your code.

So bottom line: every single framework brought something to the table, including yours. Learn to respect them and people will respect you. Throwing bricks at the existing frameworks is not nice nor smart, and drawing all attention to your framework might actually end bad.


Posted June 8, 201211:46 pm


You and Phil are making a mistake in trying to assume that Agile Toolkit has some similarities to the frameworks you already know. Agile Toolkit is not some narrow-minded framework based on some community ideas. It is a full-featured development environment based on the design of it’s predecessor AModules3, which is based on AModules2 and traces it’s roots into year 2000. Back then there were no Zend or CI. Agile Toolkit is inspired by the Graphics User Interfaces as it says on the very first page. I am proud that I owe nothing to Zend , CI or Symfony architects because quite frankly we clearly have some different ideas about framework design. That’s a good thing! Many developers find themselves more comfortable with Agile Toolkit while others not. Choice is good.

Agile Toolkit has a very strong set of idealistic concepts and principles. It approaches many things differently. This short video explains it a little: http://www.youtube.com/watch?v=bUNEHqYVOYs. It is not an easy task – to redefine ideology of web development, but I’ve done it and other people seem to like it. I’m receiving “thanks for amazing framework” now few times a week and it keeps me motivated to keep going. I’m not about building commercial empire at all.

To address your “concerns”, one of the concepts is our approach to security. Agile Toolkit stays secure by default and accounts for human err. Manual validation of GET is fun, but it’s a boring thing to force on developers. Why not make a framework which is immune to injections? Play with it: http://demo.atk4.com/demo.html?t=11

Agile Toolkit 4.2 was released practically months ago. It has delivered a full rewrite of a model layer. Most of it is very well documented: https://github.com/atk4/atk4/blob/master/lib/DB/dsql.php. The file you have discovered without comments have been added in the last few months. Before I want anyone going into there and hacking the code I need to make sure it works well and that it is fully stable. Our developers tend to read documentation carefully and this page: http://agiletoolkit.org/doc/modeltable/join or this page: http://agiletoolkit.org/learn/understand/model/db explains how relations work.

It takes time for new developers to immerse themselves into the principles but after a few months the new concepts feel natural. Code which might look cryptic to you looks simple and awesome and the level of flexibility makes it incomparable with any other frameworks you have used before.

The SQL database abstraction layer is based on PDO and works with major RDBMS vendor. noSQL databases are too diverse in the implementation but there is non-relational models too which you can use with any View in the system. Agile Toolkit takes full advantage of RDBMS features which are not present in noSQL.

You have noticed a few “flaws” in Agile Toolkit because you come from the other background. Similarly when I look at other frameworks I see how flawed they are. Just like you express your points here (which I welcome) I am also willing to express my ideas and discuss problems in conventional frameworks as well as some ideas how they can be solved. I’m not posting them on someone’s blog, I post them here under agiletoolkit.org domain. You can’t seriously expect me to praise fuelPHP, can you?

So yes, I do have some ideas how to have a better framework. Will I actually go and contribute to CodeIgniter? no. So it’s down to people like you and Phil to examine what I’m posting here, pick up some ideas and contribute them or use them for inspiration if you choose to. Have a nice weekend, Stelian and thanks for reasonable comments, it was fun replying.

Posted June 9, 201210:59 pm

As I said before, I am not a Fuel fan boy, I love it just as much as your agile toolkit, and that is just because it offers something new from it’s predecessors.

Now back to our point, you train people to trust $_GET and use it in queries because the framework fixes it for them, and you don’t want all that load on a developer. Try hiring a framework developer and you’ll get my point. However you take it, if you give me an example to write queries where I just supply $_GET['id'] as a parameter is bad. No doubts about it.

As for the other frameworks out there, each of them serve a different purpose and each of them treat architecture issues differently, otherwise you will have the same framework rewritten over and over again.

You seem like you have a bone to pick with codeigniter, so here’s my take on it: it’s stupidly easy to use. It’s the framework with the leanest learning curve of them all, and there’s no way you can argue with that. It has a shitload of problems that will stop you from using it on large scale projects, but it works and it does it well for what it was designed to do. If you start using codeigniter into a large scale application, you’re just awful as a developer.

The Symfony2 stack on the other hand is hard to learn, ridiculously hard. It’s the first framework of the new generation that actually has an architecture and sticks to it. Is all the DI good or bad? That’s for each one to judge and use as they see fit, but the fact that you know where it starts and where it goes, makes it a good, stable framework that I would use for large scale applications.

Now let’s tackle speed. Speed?! in php?! We are not seriously having this discussion. We’re talking about a scripting language that relies on interpreted code, which didn’t have a decent OOP implementation up to its version 5. Don’t get me wrong, there’s no language I love more than PHP, but the facts remain the same. So bottom line, all frameworks are slow if you look at them from this angle, including yours! Without cashing, smart usage of database interaction, lazy loading, pre-loading, threading and all the other things you can think off, all php frameworks are slow.

Just to be clear on this, I don’t have anything against your agile toolkit. It’s a framwork that people do use and for that fact alone you have my respect. But don’t go at other’s throat just because you think you do things better on some levels, it’s just not right. Working on this project since 2000 makes me think that you know what it takes in regards of time and dedication, so give all the framework developers and architects out there the well deserved respect.

Over and out, Stelian

Posted June 11, 201212:19 am

Amen! :)

Posted June 28, 20121:47 am

I have been hand coding a very large project because I did not want to take the time to learn the “language” of a framework. However, after reading this article I had to give my 2 cents. While I appreciate the comments from people with a lot more experience than I have with PHP or frameworks in general, I find it a bit distressing that grown adults would allow a conversation to get to this point. Romans of course is going to talk up his product, this is his site. That’s called salesmanship. If a Ford wins the Motor Trend car of the year I am quite sure if you go to the Chevy site they are going to point out points where they feel their product is superior to Fords. I think if we step back and stop letting emotion decide a course of action or dictate a sentence we will see that some of these comments made were truly jejune to say the least. People need to stop and think before firing comments off that truly serve no purpose. If you have a debate that is great to read, but debate the facts not the person.

Posted June 28, 20126:38 pm

Thanks Bob :) I really do not mind. Receiving negative feedback is always so much more valuable than having only a positive feedback or no feedback at all.

Gowrav Vishwakarma
Posted June 10, 20134:13 pm

I have read the full page, I wanted to, but could not skip anyone. With due respect and over 10 years of my PHP knowledge, I further add the following to the discussion:

With more then 5 PHP frameworks experience and contributing to Codeigniter community, as well as re-writing all the basics of CI to make it compatible with Joomla I am pretty sure about what I am saying.

The Agiletoolkit has changed a lot since the discussion started. I think, what romans is trying to say is cannot be understood without seeing the framework in action. Every time when romans say agiletoolkit is not as others, you still thinks it in reference of others, while agiletoolkit has its own very unique approach for web applications. At the start the documentation was not proper but today it has a good stuff.

Again my + to agiletoolkit. After seeing almost all good frameworks in some real productions, I can say with Agiletoolkit I am approx 10 times faster then any near by framework even with complex conditions…

This might be my own thinking but after a few hours demonstration, my all PHP developers (approx 30+) shifted to agiletoolkit by their will and this made me think again..

Not another framework.. I see it as whole another approach towards web application …. good work.. and all the best….