4 ms·

Just curious but why are the major php frameworks so abysmally slow? It seems like php-raw does pretty well in all the tests but most of the big frameworks (cak

by error54 13y ago

Just curious but why are the major php frameworks so abysmally slow? It seems like php-raw does pretty well in all the tests but most of the big frameworks (cake, symfony, etc) are orders of magnitude slower.

umsm 13y ago
Wow, I was floored at how slow Symfony is... I have a feeling it's ORM that's killing these frameworks in the DB portion.
- beberlei 13y ago
  it is used without caching, leading to unnecessary parsing of a metadata structure. This is explicitly not recommended for production use and kills the request time here.
- Skamander 13y ago
  Hi, I'm the user who contributed symfony 2 to the benchmark. My intention was to get as much php frameworks in the next round as possible (Symfony 2, Codeigniter, Laravel etc.), so I didn't pay much attention on the possible optimisations of the frameworks. On top of that I'm not a php guy, so it's possible that every php framework I contributed to the benchmark runs on breaks. ;o) In Symfony's case I posted on the mailing list in order to get users with symfony experience to improve the performance, but this post was sadly not activated/moderated.
1880 13y ago
A PHP framework has to initialize all its systems from zero for each request. It may because of that, it may not, it's just a guess.
- Joeri 13y ago
  You would think the frameworks would be designed around that, loading the absolute minimum of code to handle the request.
  - jtreminio 13y ago
    Lazy Loading is a thing with modern PHP frameworks.
    - Joeri 13y ago
      I'll give an example: zend_validate uses a proper OO hierarchy, so that for each type of validation (maxlength, digits, ...) there's a distinct validator class, which has to be instantiated prior to being applied to a piece of data. The whole thing is really clean and organized ... and abysmally slow, because on each request you're loading dozens of validator classes. That would have been much faster had it been a simple ugly procedural API with all its code in one file. The per-request overhead of input validation is more important than a 'pure' oo design in my opinion.
  - k3n 13y ago
    That still doesn't prevent you from needing to do that on each request. Also, with most frameworks, they're usually quite complex; how else are you going to be everything for everyone? Complexity comes at a cost, most notably in framework land this takes the form of code with very tall inheritance structures and/or tons of dependencies. You need Foo? Ok, Foo inherits from BaseFoo, which inherits from CoreBaseFoo, which inherits from the Widget class, which itself is a BaseWidget, etc. Let's implement a few interfaces too, and now load in various dependencies... pretty soon that simple, 5-line class that you implemented now requires 100+ classes. Things like op-code caching can greatly reduce this per-request penalty, but it doesn't change the fact that it still happens.
    - Joeri 13y ago
      Except that nothing says that you need deep class hierarchies. In fact, i think heavy use of classes and class hierarchies is an anti-pattern in PHP because of its procedural per-request model. Typically php frameworks follow a java-style model of unserializing data into objects, loading the corresponding class files on-demand, calling API's on the objects, and then reserializing. It is _much_ faster if you treat the data as a stream, cutting it up and transforming it as it passes through your code, without ever building up an object representation, and not doing any more deserialization than a simple json_decode (which is really fast). This is in fact the original PHP model, transforming a stream of annotated HTML.
- deleted 13y ago
  [deleted]
jtreminio 13y ago
> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/php-symfony2/src/Skamander/BenchmarkBundle/Controller/BenchController.php https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... Doctrine is slow, and this is not how you would use it in the real world. Throwing a cache on top of everything will speed it up considerably.
- bhauer 13y ago
  We have expressly avoided caching in these tests (so far) in order to exercise the ORM and database connectivity. In future tests, we plan to introduce caching [1]. If you have thoughts about specific test characteristics you'd like to see when caching is added, I'd like to hear those thoughts. Thanks for the feedback! [1] https://github.com/TechEmpower/FrameworkBenchmarks/issues/133 https://github.com/TechEmpower/FrameworkBenchmarks/issues/13...
  - beberlei 13y ago
    Doctrine is explicitly not suitable for non cache usage. You should remove the ORM from the test and use the DBAL only instead if you don't have caching introduced. Additionally you are not bootstrapping the Symfony cache correctly, you need to run "php app/console cache:clear --warmup --env=prod --no-debug" before running the tests, it might cause cache slams in your benchmarks.
    - newbie12 13y ago
      Correct, running the debugging bar in Sf2 will kill performance.
  - fooyc 13y ago
    At least the annotation/metadata/dql parser cache should be enabled: metadata_cache_driver: apc Else you are benchmarking the annotation and DQL parsers. Also, for big PHP frameworks you have to make sure that APC's SHM size is large enough.
ayi 13y ago
running apt-get install php5-apc;/etc/init.d/apache restart command will (at least) make it 3 times faster. apc is no-config, no-cost php accelerator :)
- krg 13y ago
  All the PHP tests were done with PHP 5.4.13 with APC, PHP-FPM, running behind nginx because previous feedback suggested this was optimal. http://www.techempower.com/benchmarks/#section=environment http://www.techempower.com/benchmarks/#section=environment

by error54 13y ago

umsm 13y ago

Wow, I was floored at how slow Symfony is... I have a feeling it's ORM that's killing these frameworks in the DB portion.

beberlei 13y ago
it is used without caching, leading to unnecessary parsing of a metadata structure. This is explicitly not recommended for production use and kills the request time here.
Skamander 13y ago
Hi, I'm the user who contributed symfony 2 to the benchmark. My intention was to get as much php frameworks in the next round as possible (Symfony 2, Codeigniter, Laravel etc.), so I didn't pay much attention on the possible optimisations of the frameworks. On top of that I'm not a php guy, so it's possible that every php framework I contributed to the benchmark runs on breaks. ;o) In Symfony's case I posted on the mailing list in order to get users with symfony experience to improve the performance, but this post was sadly not activated/moderated.

1880 13y ago

A PHP framework has to initialize all its systems from zero for each request. It may because of that, it may not, it's just a guess.

Joeri 13y ago
You would think the frameworks would be designed around that, loading the absolute minimum of code to handle the request.
- jtreminio 13y ago
  Lazy Loading is a thing with modern PHP frameworks.
  - Joeri 13y ago
    I'll give an example: zend_validate uses a proper OO hierarchy, so that for each type of validation (maxlength, digits, ...) there's a distinct validator class, which has to be instantiated prior to being applied to a piece of data. The whole thing is really clean and organized ... and abysmally slow, because on each request you're loading dozens of validator classes. That would have been much faster had it been a simple ugly procedural API with all its code in one file. The per-request overhead of input validation is more important than a 'pure' oo design in my opinion.
- k3n 13y ago
  That still doesn't prevent you from needing to do that on each request. Also, with most frameworks, they're usually quite complex; how else are you going to be everything for everyone? Complexity comes at a cost, most notably in framework land this takes the form of code with very tall inheritance structures and/or tons of dependencies. You need Foo? Ok, Foo inherits from BaseFoo, which inherits from CoreBaseFoo, which inherits from the Widget class, which itself is a BaseWidget, etc. Let's implement a few interfaces too, and now load in various dependencies... pretty soon that simple, 5-line class that you implemented now requires 100+ classes. Things like op-code caching can greatly reduce this per-request penalty, but it doesn't change the fact that it still happens.
  - Joeri 13y ago
    Except that nothing says that you need deep class hierarchies. In fact, i think heavy use of classes and class hierarchies is an anti-pattern in PHP because of its procedural per-request model. Typically php frameworks follow a java-style model of unserializing data into objects, loading the corresponding class files on-demand, calling API's on the objects, and then reserializing. It is _much_ faster if you treat the data as a stream, cutting it up and transforming it as it passes through your code, without ever building up an object representation, and not doing any more deserialization than a simple json_decode (which is really fast). This is in fact the original PHP model, transforming a stream of annotated HTML.
deleted 13y ago
[deleted]

jtreminio 13y ago

> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/php-symfony2/src/Skamander/BenchmarkBundle/Controller/BenchController.php https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... Doctrine is slow, and this is not how you would use it in the real world. Throwing a cache on top of everything will speed it up considerably.

bhauer 13y ago
We have expressly avoided caching in these tests (so far) in order to exercise the ORM and database connectivity. In future tests, we plan to introduce caching [1]. If you have thoughts about specific test characteristics you'd like to see when caching is added, I'd like to hear those thoughts. Thanks for the feedback! [1] https://github.com/TechEmpower/FrameworkBenchmarks/issues/133 https://github.com/TechEmpower/FrameworkBenchmarks/issues/13...
- beberlei 13y ago
  Doctrine is explicitly not suitable for non cache usage. You should remove the ORM from the test and use the DBAL only instead if you don't have caching introduced. Additionally you are not bootstrapping the Symfony cache correctly, you need to run "php app/console cache:clear --warmup --env=prod --no-debug" before running the tests, it might cause cache slams in your benchmarks.
  - newbie12 13y ago
    Correct, running the debugging bar in Sf2 will kill performance.
- fooyc 13y ago
  At least the annotation/metadata/dql parser cache should be enabled: metadata_cache_driver: apc Else you are benchmarking the annotation and DQL parsers. Also, for big PHP frameworks you have to make sure that APC's SHM size is large enough.

ayi 13y ago

running apt-get install php5-apc;/etc/init.d/apache restart command will (at least) make it 3 times faster. apc is no-config, no-cost php accelerator :)

krg 13y ago
All the PHP tests were done with PHP 5.4.13 with APC, PHP-FPM, running behind nginx because previous feedback suggested this was optimal. http://www.techempower.com/benchmarks/#section=environment http://www.techempower.com/benchmarks/#section=environment