Hacker News Reader

Comment by rustc | Hacker News Reader

I wonder why the 9 lowest ranked frameworks are all in PHP...

Not that PHP is particularly fast, but I notice that Raw PHP does about middle of the pack, but all of the ORM versions seem to do terribly. Interesting stuff.

I've usually had pretty good luck with Slim, I'll have to try a version with & without redbean and see how big a difference it makes.

Probably because all those big frameworks have to initialize everything for every request. Parsing, connections, configuration, you name it.

Yeah, of course.

With slim in particular I notice that the benchmarks list it as "Raw database connectivity" but in the code it looks like it's using RedBean ORM. I'll look more at lunch, i'm probably just misreading something.

Although obviously ORM is more realistic, since if you're sophisticated enough to be using composer and a framework, you're probably using an ORM. I know the point of this benchmark is frameworks not ORMs, but it would be interesting to swap them out and see if there's a huge difference.

Raw php also has to initialize connections, and it does really well, so I don't think that's it. To me, that points to overhead from initializing the objects as the bottleneck. I would have thought that with APC, this wouldn't be a major issue, though, so I wonder if that's still not it.

APC only caches the opcodes, so the interpreter doesn't have to parse your code. But the framework still has to set up itself for each request individually. Parse configuration, create objects, etc. It adds up quickly.

I always hear this myth that php gets very slow when you write proper OO code. I neither write nor maintain any php code so I wouldn't know.

Is there no php environment with a persistent server? Are they really all doing per request startup?

Yes. The PHP process keeps running but resets completely on every request. The bytecode is cached though, so loading the code shouldn't add much overhead.

PHP can be used for long-running jobs, but it doesn't have very good garbage collection, and has no language-level concurrency and very little asynchronicity.

Well, you could daemonize a PHP process, which would listen to some port, and parse the requests. It's like implementing your web server in PHP.

The problem with it is, one request can bring the whole thing down.

Actually, as soon as a lot of db connections are involved, PHP jumps to the head of the pack.

Which means that in most common web use cases (which are db heavy), PHP is as fast as any of them, since all the slowdowns (initialization, slow Zend engine etc) are dwarfed out by the fast db handling.

Raw PHP (with no framework, no ORM) does well in the 20 query test, but unfortunately you have to go down pretty far before any of the PHP frameworks show up on that list.

If I filter to just show PHP, the 20 query test shows that the first framework is less than 50% the performance of raw PHP.

Looking into the code, the raw PHP is using PDO with persistent connections, and I'm not sure that's turned on in any of the frameworks.

It looks like it's off by default in Redbean at least. No idea if this makes a big difference, I haven't had time to try it out.

Yes, it does look like none of the frameworks are using persistent connections, which would explain the horrible performance. To be fair though, it is still a valid measurement if the frameworks don't enable persistent connections by default.

> it is still a valid measurement if the frameworks don't enable persistent connections by default

I don't agree. Frameworks often prefer the "safe" option over "performance" by default. If you activate persistent connections by raw coding it [1] then you should also set an absolutely obvious database configuration flag like [2] in a framework.

---

[1] https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

[2] https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

If their FAQ's page is saying what I think it does, then they aren't testing with memcache or opcode caching.

Also no love for Yii.

We are using opcode caching.

"PHP 5.4.13 with APC, PHP-FPM, nginx"

http://www.techempower.com/benchmarks/#section=environment

We've had a lot of input from the PHP community about setting up the PHP tests properly, but if you have a suggestion for an improvement we'd appreciate it.

Memcache isn't used because none of the tests are caching database results. A later test will use caching.

We'd be happy to include Yii. Submit a pull request. :)

Someone mentioned the benchmark in the Yii forum a while ago [1], but it seems nobody wanted to submit a pull request for Yii.

[1] http://www.yiiframework.com/forum/index.php/topic/42168-fram...

Because you didn't scroll past the first graph?

Reply on news.ycombinator.com