Live data from Hacker News

Web Framework Benchmarks

techempower.com

121–130 of 415 posts

Re: Web Framework Benchmarks

#121
A few additions/tweaks that would be great to see:

1) Add a raw http test -- no template compilation or html, just return "OK". Would give a relative idea of the cost to "just turn the thing on"

2) Don't json encode after the database tests. By json encoding you're doing two things but saying you're only testing one.

I come from the python/django world, and I know that different python json packages have orders of magnitude differences in their performance. From that I can infer that there are probably similar or greater cross-language differences -- I suspect node.js having json as a native object type helps immensely.

Re: Web Framework Benchmarks

#122
post #59
post #35

Would love to see how modern Perl frameworks (Mojolicious/Dancer) ranks in such a test.

[deleted]

"Oh, they're just frameworks for CGI/Perl and thus severely crippled by CGI's mode" - This isn't true.

Dancer use PSGI (not CGI) and most modern Perl webapp frameworks (Mojo & Catalyst) use PSGI/Plack (http://plackperl.org/). The PSGI model is very similar to wsgi which allows for different types of persistent servers.

Dancer's deployment POD is good reference on options: https://metacpan.org/module/Dancer::Deployment

Re: Web Framework Benchmarks

#123
I'd be curious to see how ruby fares using a setup other than apache + passenger; I have a feeling that nginx with unicorn or puma would provide better results, and might give it a go when I have a bit more time.

Re: Web Framework Benchmarks

#125
post #118
post #110

Im surprised to see that Sinatra on JRuby often performs worse than Sinatra on MRI, while Rack on the other hand performs much better.

We were surprised by the sinatra-jruby tests as well. If you read our "expected questions" section, it's not clear to us why Sinatra's performance on JRuby was weak. We'd love to hear from a JRuby expert about how to address Sinatra's "wrong" looking numbers.

Having had a look at the Gemfiles, it might be the choice of HTTP server used. I believe defaults to WEBrick, if no other server is present and I believe WEBrick is single-threaded.

I don't have any experience with JRuby, but this might be a possibility.

Re: Web Framework Benchmarks

#126
post #26

Earlier quoted context omitted.

I think this is a much needed and excellent point to make. Just take a look at how Go dips down when using Webgo.

I'm curious about that - because there's so little to webgo I suspect the answer is something really trivial. I haven't really looked at it before, but the framework itself is just 500 lines or so unless I'm looking at the wrong one... Given that the json marshalling and server components would be exactly the same between go and webgo, I'm curious as to whether changing the url recognised to be just /json in the gowe…

Just had a look at the tests and the urls responded to differ:

http://localhost:8080/json

http://localhost:8080/(.*)

Shouldn't all these examples at least be trying to do the same sort of work? For such a trivial test differences like that could make a huge difference to the outcome.

It's great to see replicable tests like this which show their working, but they do need to be testing the same thing. I also think they should have something more substantial to test as well as json marshalling on all the platforms, like serving an HTML page made with a template and with the message, as that'd give a far better indication of speed for tasks web servers typically perform.

Still, it's a great idea and really interesting to see this sort of comparison, even if it could be improved.

Re: Web Framework Benchmarks

#128
post #26

One of the most interesting things this comparison brings out to me is not so much the differences between the various frameworks (although the differences between options on the same platform is definitely very useful information), but also the issue that few of us seem to think about these days: the cost of any of the frameworks above the bare standard library of the platform its hosted on. Theres a consistant, con…

I think this is a much needed and excellent point to make. Just take a look at how Go dips down when using Webgo.

I'm not sure many people would use webgo in real life. I don't know... maybe some people... certainly not pros.

Also, the 1.0.3 thing is probably dragging on the numbers a bit. 1.1 would boost it a little. Not enough to get it into the top tier... but a little.

Also, for Vert.x, they seem to be only running one verticle. Which would never happen in real life.

Play could be optimized a bit... but not much. What they have is, to my mind, a fair ranking for it.

Small issues with a few of the others but nothing major. I think Go and Vert.x are the ones that would get the biggest jumps if experts looked at them. And let's be frank... does Vert.x really need a jump?

So what they have here is pretty accurate... I mean... just based on looking through the code. But Go might fare better if it used tip. And Vert.x would DEFINITELY fair better with proper worker-nonworker verticles running.

Re: Web Framework Benchmarks

#130
post #124

Was Play 1 or Play 2 tested? I thought Play ran on Netty so I'm surprised it didn't fair better.

They're using Play 2.1 with Java, without using futures for database queries. Not sure how representative of real usage that would be, though.
Post reply on HN