Live data from Hacker News

Web Framework Benchmarks Round 4

techempower.com

31–40 of 358 posts

Re: Web Framework Benchmarks Round 4

#31
It's impressive how well PHP holds up with many queries per request (which is the most common CRUD/webapp scenario).

While for no or just one query it's slower than a lot of the other frameworks (due to PHP being slow to parse, startup etc), as soon as we have a lot of DB queries, the C interface to MySQL leaves the other frameworks in the dust.

The well known PHP shortcomings aside, that's a nice example of optimizing for the things that matter most, especially for it's common use cases (Wordpress, Drupal, etc).

Re: Web Framework Benchmarks Round 4

#32

Good to see Java is holding its own.

Really. I've recently been getting into node/express after years of Java, and these results make me feel a whole lot less cool.

Well no matter what you use, you should always benchmark for that exact reason. Making things go fast takes a lot of performance engineering, and the JVM has millions of dollars worth of tuning put into it.

BTW, if you like Node.js, you should probably look at Vert.x. I haven't used it, but it's a similar concept, it runs on the JVM, and it seems to spank Node.js.

Re: Web Framework Benchmarks Round 4

#33

Good to see Java is holding its own.

Really. I've recently been getting into node/express after years of Java, and these results make me feel a whole lot less cool.

I got on the Node thing for awhile too, but went back to Java/JBoss/Tomcat/Spring. If you are skilled with the Java stack it is hard to beat for performance and breadth. If you are not, well, I admit the learning curve is steep.

Re: Web Framework Benchmarks Round 4

#34
post #16
post #2

This is the most recent update to our ongoing project measuring the performance of web application platforms and frameworks. In this round we've received several more community-contributed tests in Perl, PHP, Python, Java, and JavaScript. Go is a comeback champion thanks to changes made by Brad Fitzpatrick [1] and others in the Go community. A new "Fortunes" test was also added (implemented in 17 of the frameworks) t…

Any reason you didn't test ASP.NET MVC or ASP Web Forms?

We would like to have a .NET test running on mono. We were hoping to get a pull request for round 4, but unfortunately we have yet to receive one.

Re: Web Framework Benchmarks Round 4

#35
post #11

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.

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.

Re: Web Framework Benchmarks Round 4

#36
Off all the top performers, Go seems to be the only sane choice to write a web app. Moreover it is at the sweet spot; expressive, flexible, simple, super performant, good community etc. I think it is convincing enough for me to give Go a serious look for our new app.

Re: Web Framework Benchmarks Round 4

#37
post #28

Earlier quoted context omitted.

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.

Re: Web Framework Benchmarks Round 4

#38
post #35

Earlier quoted context omitted.

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.

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

Re: Web Framework Benchmarks Round 4

#39
post #11

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.

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.

Re: Web Framework Benchmarks Round 4

#40
post #31

It's impressive how well PHP holds up with many queries per request (which is the most common CRUD/webapp scenario). While for no or just one query it's slower than a lot of the other frameworks (due to PHP being slow to parse, startup etc), as soon as we have a lot of DB queries, the C interface to MySQL leaves the other frameworks in the dust. The well known PHP shortcomings aside, that's a nice example of optimizi…

In really scalable sites, you need sharding. Unless your database itself is doing the scaling (such as with Riak), you're going to sometimes hit multiple shards. With PHP and other languages that can't do async, you're going to have to query the DB sequentially, increasing latency proportionally to the number of shards you have to hit. With Node.js and other asynchronous apps, you don't.

Disclaimer: mysqli does have async capabilities, but most people such as myself use PDO for its other benefits. And mysqli only works with MySQL.

Post reply on HN