Hacker News Reader

Comment by error54 | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

You would think the frameworks would be designed around that, loading the absolute minimum of code to handle the request.

Lazy Loading is a thing with modern PHP frameworks.

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.

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.

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.

> 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.

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/13...

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.

Correct, running the debugging bar in Sf2 will kill performance.

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.

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 :)

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

Reply on news.ycombinator.com