I benchmarked “quick start” projects. That gives some idea on what is the base line for every framework and makes it possible to reproduce my tests (and argue against them).
Code was hosted on Amazon EC2 medium instance. I installed PHP-APC to avoid disc access and code parsing. I also made sure there is no I/O on Apache2 or application level. I set logs and cache paths to “/dev/shm/”. I tweaked projects to make them return roughly the same amount of data (10KB). All virtual hosts had the same mod_rewrite rules. AllowOveride was set to None.

Benchmarked frameworks:

• Cake PHP
• Code Igniter
• Fuel PHP
• Hazaar MVC
• Kohana
• Laravel
• Netter
• Phalcon
• Silex
• Slim Framework
• Symfony 2
• YII
• Zend Framework 1
• Zend Framework 2

Requests per second from Apache Benchamrk with c=20 and n=500.

I’m not surprised, Slim is the fastest because it’s a micro framework. The Quick Start project didn’t use any templates or layout which obviously contributed to the reading.
Zend1 is twice faster than Symfony2 and Zend2 but in my experience the number will quickly go down in a real live setup.

Frameworks should speed up development, performance is a secondary concern. Zend 2 and Symfony2 could do better but it’s not bad. There are ways to improve those numbers on production servers. Don’t reinvent the wheel, learn and use frameworks. There are various options which balance between performance and features.

ps. If you have space for more I would like to recommend you great research on performance of web frameworks by techempower.

ps2. Thank you for your suggestion Ron. Phalcon is the new winner.

The benchmark was performed with following software:
– WordPress – tested application.
– ab (apache benchmark) – measuring software
– APC (alternative php cache) – I wanted to benchmark computing power not hard drive I/O

WordPress site had 2 “Lorep Ipsum” posts (changing number of posts will change benchmark figures) with few categories, tags and an image. I benchmark each setup from the same remote host with 50 concurrent connections and performed 500 requests (ab -c 50 -n 500). Tested URL was homepage.

The most striking conclusion from this tests is that 4 small instances gives as much power as 2 medium or 1 large. They also cost the same. Some solutions might benefit from distributed setup so when one instance falls there are 3 more. On the other hand large instance has 4 time more RAM which might be more appropriate for some extensive caching strategy.
It gets little bit more interesting with requests per second divided by cost per hour.

The “High CPU” group visibly stands out. When you need multiple web frontends it looks like the best choice is the “High CPU – medium” instance. It gives the best value for the money. At the moment of writing this article the instance comes with following parameters:

1.7 GiB of memory
5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each)
350 GB of instance storage
32-bit or 64-bit platform
I/O Performance: Moderate
EBS-Optimized Available: No
API name: c1.medium

It’s worth to mention that “High CPU – High” offers High I/O performance. My WordPress benchmark couldn’t benefit from that because PHP code was cached in memory. I can imagine that for some type of applications it might be an important requirement.

Will Gloople move to AWS ecosystem? I don’t know. There are many other factors which need to be taken under consideration. Nevertheless it was fun to learn little bit more about Amazon and their pricing schema. EC2 instances look very similar and it’s tempting to skip testing and go for a bunch of small servers. This examples shows that sometimes it pays to do homework.