What is the world's fastest PHP based framework? Web site owners want the fastest performing framework to give fast customer response and to rate higher in Google. Web site owners also want fast development when they are paying for development by the hour. Web site owners also want to add new things, requiring flexibility.
Both flexibility and fast development conflict with fast performance. There are all sorts of tricks to make slow sites appear faster, they all cost setup time, they all require ongoing work, they all eat into flexibility, and they usually conflict with each other, limiting you to one major choice. If you can make the underlying framework faster, the speedup will work with any of the tricks, giving you a double advantage,
Find the best framework for you
Your requirements are different to everyone else. Your requirements for your next project will be different. Developers want something to make development easier, Web site owners want something to make Web site ownership easier. For most Web sites, a content management system is a better starting point than a framework. Drupal is the best example of a content management system.
Frameworks usually have less than what you need while having a lot of things you do not need. Typically less documentation than you need the first time you use the framework. Luxuries, such as ORM, are useful for some big projects and are mostly bloat. The best option is to have the luxuries available but not as part of the core package, not as a compulsory overhead.
If you know people already using frameworks and contributing to the development of the frameworks, ask them about their usage and their expectations for the future. There is always a new release that fixes something but some frameworks have slow development cycles and some frameworks have unreliable new features. You want a framework that is evolving without constantly undergoing revolutions.
As a developer, you want something you can work on and contribute enhancements back to the project. As a Web site owner, you want something popular so you can find other experienced developers when your current developer leaves.
Phalcon is the clear winner for speed because it is written in the C language as a PHP extension. But is Phalcon practical?
Can you code in C? If yes, you could contribute code enhancements to Phalcon. If not, Phalcon is a black box you cannot work on, you cannot fix if it breaks, and you cannot extend. Anything you need to add, has to be added in PHP and runs at the slower speed of PHP.
The total speed of your Web site will depend on the ratio of Phalcon processing to your PHP code. One simple benchmark, using almost raw framework code, shows Phalcon twice as fast as the nearest competitor. When you look at benchmarks based on full Web sites, Phalcon drops back to just a little bit faster because most of the processing is outside Phalcon.
Phalcon for full Web sites will improve as Phalcon expands but you will not be able to contribute to the expansion if you cannot code in C.
A potential second place
You could choose an efficient framework, develop your site, then compile the PHP code to get performance similar to Phalcon.
There are several PHP code compilers in development and none are ready for reliable general purpose use. For a brand new project with endless development time, look at PHC, www.phpcompiler.org, and HipHop PHP, github.com/facebook/hhvm.
HipHop PHP is used for some big Web sites. PHC should be useful but appears to have stalled after HipHop PHP attracted all the media attention. PHC is the right way to go long term and has less limitations, compared to HipHop.
BinaryPHP will convert PHP to C then you compile the Code, an option you might prefer if you have to mix in external C code.
Slim is consistently the fastest pure PHP framework in simple speed tests but is a slim/lightweight/limited framework and might not do what you want. You might find you can develop some Web sites using Slim but have to use something else for bigger projects. Learning and using two frameworks is too hard. Test Slim and be prepared to either contribute to Slim or build a layer over the top of Slim or switch to a fuller function framework. read more...
Kohana, kohanaframework.org, is a HMVC framework. HMVC is better than MVC for large projects. Kohana is written for PHP5 and simplicity. ORM and similar extravagances are in separate modules, giving you the choice to use or not use.
Kohana is a good choice for dedicated single purpose Web sites. You might have a site dedicated to providing product information as a web service and want to exclude from the framework everything not required for the service. You can load Kohana without the fancy user interface, without ORM, without database independence, giving you a light code base similar to Slim.
Fuel, fuelphp.com, scores well in some benchmarks and is down towards the middle in others.
Fuel is headed down the same path as many other frameworks and may lose all distinctive characteristics. As an example, Fuel now uses Composer, the same as many other frameworks.
CakePHP, cakephp.org, used to be the new kid on the block and introduced some good ideas. now it is dropping out of popularity because there are many other frameworks doing the same thing.
Before PHP was invented, code generation was popular. CakePHP made some of the generation techniques popular to the point where CakePHP is buried by look-alikes.
codeIgniter used to be popular and fast but is now obsolete and only in the middle of the performance benchmarks.
Hazaar MVC, www.hazaarmvc.com, has a Web site suggesting Hazaar MVC has only one author and the author does not like PHP. I would not bother trying the framework.
The site suggests Hazaar MVC is the fastest framework but when you read why it is supposed to be fast, it is doing the same things as the current versions of many other frameworks. Hazaar MVC performs in the middle of the benchmarks along side other frameworks doing the same thing.
The Laravel frameworks gets good recommendations, is near the top in some benchmarks, and is in the middle of other benchmarks.
Laravel is another framework built on Symfony, or using Symfony components. I cannot see a reason to use Laravel instead of full blown Symfony. Laravel already contains more than I need for my small projects and my large projects would be better off using Symfony to allow future expansion.
Nette, nette.org, is a framework from Czech Republic and promising
PHPDevShell, www.phpdevshell.org, is some sort of page delivery framework, an outline for a Web site waiting for your PHP code. I can see a use for PHPDevShell for some applications but not public Web sites. I doubt it would be ideal for replying to Ajax type requests because PHPDevShell includes stuff not needed for that type of service.
Prado, www.pradosoft.com, looks interesting as a sightly different approach. The performance does not stand out in any benchmark.
I looked at Prado for a highly interactive application/site combination. Prado could be nice for the interactive application but not for the content site hosting the application. Prado has a different template system not compatible with anything else. If you commit to Prado, you are committed to a lot of things not reusable anywhere else. My project required a Web site framework anyone could work on and I could not see a way to use Prado for an application inside a content management system or another framework.
Prado might be useful for a site dedicated to servicing Ajax style requests if your team is big enough to support two frameworks.
Silex, silex.sensiolabs.org, is a cut down version of the Symfony framework. From what I can see of Silex, it would fit none of my projects. Silex does things I do not need for my small projects. For anything bigger, I would have to use Symfony.
Yii is consistently in the middle of benchmarks. All the press is about Yii being good for developers, not about performance. When you look into Yii, Yii is doing the same things as most other frameworks and should get similar results, as demonstrated in benchmarks.
The one current negative for Yii is the big rewrite for version 2. Yii 2 is too far away to tell what it will be like. The discussion forum about the development of Yii 2 is full of suggestions that make Yii version 1 look bad. Why are they suggesting improvements for version 2 that are already in frameworks older than Yii version 1?
Yii 1 looks a touch immature and Yii 2 looks like it will be closer to the other look-alike frameworks. read more in Yii.
The Zend Framework version 2, http://framework.zend.com/, is consistently the slowest PHP framework in many benchmarks. Zend Framework version 1 was near the bottom of many benchmarks and version 2 is twice as slow. The only reason for learning Zend is to get a job in a big corporation.
Features you might look for
Some applications start a page request by reading a huge range of configuration settings from a database or a splatter of YAML files. Modern code extracts the configuration information and generates code to use the information. The first time I wrote a PHP framework, I used code generation from a framework I wrote before PHP appeared.
Code generation was common in PHP but was not fashionable because PHP code caches were more popular and code caches did not work easily with generated code, plus the most common configuration of low code hosting was also incompatible.
Years later Ruby on Rails became fashionable and included code generation they named
scaffolding. Suddenly there was a flood of PHP based frameworks promising scaffolding.
The best scaffolding results in code generation when a configuration value changes. Ruby on Rails went backwards to use the slower constant generation of code for every page. Some PHP frameworks slavishly follow the worst of Ruby on Rails while other frameworks use the best type of code generation.
Most benchmarks start with a
Hello world test not using a database. The instant you add a database access, things slow down. Half speed, quarter speed, part of the slowdown depends on the code loaded and part on the configuration of the database.
If you run a benchmark of frameworks performing a few basic database accesses and all the frameworks slow down to similar speeds, the speed limitation is the configuration of the database software, not the framework. When you allocation more resources to the database, you should get a bigger difference.
Database independence produces a bigger slowdown than database specific code because there are compromises made to fit other databases. Typically some of the fast parts of MySQL are not used because they are not compatible with other databases. Data is stored in slower formats to avoid an efficient format supported by only one database.
Database results caching is another slowdown. Good database software caches results if given enough memory and the right configuration. Some frameworks and content management systems attempt to duplicate the database caching, a real heavy resource chewing hog. Your application might not benefit from the overhead of caching in the framework. You might have to double memory size to accommodate the extra overhead. There are lots of problems caused by caching.
Caching is of most benefit when it is applied to the end result of a page request. If your weather report page receives an update from the weather department once every hour, you could generate the page once per hour and keep the generated page cached. This is completely different to caching the database requests used to build the page.
You want the absolute minimum database code to do exactly what you need and nothing else. it is nice to then have the option to add in expanded database support for bigger projects. For instance, ORM should be optional, not built in.
Initial code load
Most of the frameworks claim to be fast because they load code only when requested. The difference is the amount of code loaded before they start loading code by request. Some memory measurements from trivial code tests show Symfony, Yii, and Zend consuming twice the memory of Fuel and Fuel is not the best.
There are many examples of failures in this area. Drupal is an extremely flexible content management system and loads tons of code to provide the flexibility. Over the years Drupal has developed a huge range of features using Ajax. Unfortunately Drupal loaded heaps of stuff that was useless for Ajax. Drupal 7, the latest version, split Drupal code loading into two steps with only the first used for Ajax responses. The next version of Drupal, Drupal 8, loads more code on demand and less during the initial load, to make Ajax responses faster.
Ajax and equivalents are taking over the Web page. If you are starting fresh with a new framework, you really need a low initial overhead. For projects big enough to accommodate two frameworks, you might use Phalcon for answering the Ajax requests and a more flexible framework for the main Web site.