Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Framework Benchmarks

techempower.com

Post reply on HN
Print view View original

111–120 of 415 posts

Re: Web Framework Benchmarks

#111

Post by saym »

What I'd love to see paired with this data is a cost comparison. At what scale does performance of ruby/python/php become cost prohibitive? Twitter made the move from Ruby to Java some years back, did they ever post a comparison of their numbers before and after?

Also, the difference between EC2 and local i7 hardware is glaringly obvious. At what scale does owning the server hardware become imperative?

I know these questions are beyond the scope of a performance review, but inquiring minds would like to know.

Re: Web Framework Benchmarks

#112

Post by knappador »

Utter crap.

"Sadly Django provides no connection pooling and in fact closes and re-opens a connection for every request. All the other tests use pooling."

But it's free, open-source software and we provide asynchronous database connection pooling for Postgres SQL:

https://github.com/iiilx/django-psycopg2-pool

Re: Web Framework Benchmarks

#114

Post by kainsavage »

saym wrote: post #111

What I'd love to see paired with this data is a cost comparison. At what scale does performance of ruby/python/php become cost prohibitive? Twitter made the move from Ruby to Java some years back, did they ever post a comparison of their numbers before and after? Also, the difference between EC2 and local i7 hardware is glaringly obvious. At what scale does owning the server hardware become imperative? I know these q…

Actually, we had an early revision of the benchmark tests that had exactly that analysis, but we really felt it is a very interesting subject that deserves more focus.

Re: Web Framework Benchmarks

#115

Post by bhauer »

saym wrote: post #111

What I'd love to see paired with this data is a cost comparison. At what scale does performance of ruby/python/php become cost prohibitive? Twitter made the move from Ruby to Java some years back, did they ever post a comparison of their numbers before and after? Also, the difference between EC2 and local i7 hardware is glaringly obvious. At what scale does owning the server hardware become imperative? I know these q…

As you might imagine, during this exercise, we've had a lot of conversations about the points you raise. We have our own opinions, but we ultimately removed most of that content from the blog post because we didn't want it to be too editorial. We will be posting follow ups with some of our opinions.

Some things are really difficult to answer in a vacuum. If you already have a competent devops staff, hosting your own hardware is probably beneficial. The increased performance per "server" is substantial. But no devops staff? Then it's either very risky or cost-prohibitive to own hardware.

Re: Web Framework Benchmarks

#116

Post by sluukkonen »

bhauer wrote: post #92
goodwink wrote: post #77

Earlier quoted context omitted.

Here's a quick version of the framework optimization index. Higher is better (ratio of framework performance to raw platform performance, multiplied by 100 for scale): Framework Framework Index Gemini 87.88 Vert.x 76.29 Express 68.85 Sinatra-Ruby 67.88 WebGo 51.08 Compojure 45.69 Rails-Ruby 31.75 Wicket 29.33 Rails-Jruby 20.09 Play 18.02 Sinatra-Jruby 15.96 Tapestry 13.57 Spring 13.48 Grails 7.11 Cake 1.17

It's funny you should put this together because in an earlier draft of this blog entry I had created a tongue-in-cheek unit to express the average cost per additional line of code. Based on our Cake PHP numbers, I wanted to describe PHP as having the highest average cost per line of code. But we dropped this because I felt it ultimately wasn't fair to say that based on the limited data we had and it could be easily i…

For Play, you'll want to either 1) handle the (blocking) database queries using Futures/Actors that use a separate thread pool (this might be easier to do in Scala) or 2) bump the default thread pool sizes considerably. The default configuration is optimized purely for non-blocking I/O.

See e.g. https://github.com/playframework/Play20/blob/master/document... and https://gist.github.com/guillaumebort/2973705 for more info.

Re: Web Framework Benchmarks

#118

Post by bhauer »

waxjar wrote: 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.

Re: Web Framework Benchmarks

#119

Post by lorddamien »

akg wrote: post #55

Would love to see how these results compare to some of the web frameworks for concurrent functional languages like Erlang/Haskell: Nitrogen, Chicago Boss, Snap, Yesod, etc.

Right, where is Zotonic??, which is actually focused on speed/performance

Re: Web Framework Benchmarks

#120

Post by bigpresh »

[deleted] wrote: post #59
eCa wrote: post #35

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

[deleted]

No, they're not. They can run via CGI (so, yes, compiled for each request) but that's slow as ass. They run via Plack/PSGI - they can be deployed in a multitude of ways, including via FastCGI or running standalone using built-in webservers, or via Starman - the latter in particular is very fast indeed. With a simple "hello world" type app, > 6000 requests/sec can be easily handled. Obviously an app of more realistic complexity won't be quite that fast, but you'll still handle many requests every second with no trouble. http://stackoverflow.com/a/4770406/4040 contains some basic benchmarks.

EDIT: also, mod_perl is generally best avoided these days; it's old, not very pleasant to work with, and ties you to Apache. Writing an app with Dancer / Mojolicious etc means you can deploy in various different ways with ease.

Post reply on HN