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

191–200 of 415 posts

Re: Web Framework Benchmarks

#191

Post by pilgrim689 »

markokocic wrote: post #143
papsosouid wrote: post #141

Earlier quoted context omitted.

>Given the amount of interest in Haskell I see more people making uninformed "haskell sucks" posts than expressing interest in it. >and Yesod Really? Yesod is the anti-haskell haskell framework.

> Really? Yesod is the anti-haskell haskell framework. Can you please elaborate. Being interested in Haskel web development and trying to choose web framework makes me wish for more information.

I wouldn't call Yesod "anti-haskell". By default, it relies on QuasiQuotes and TemplateHaskell a lot [1], which are extensions to the GHC. So by default, you'd have a hard time running Yesod applications on anything else but GHC (the Glasgow Haskell Compiler). These extensions allow you to write in an EDSL that generates Haskell for you. IMO, Yesod's use of these extensions are a benefit, as it allows the user to get stuff like type-safe URLs in HTML for free (e.g. you put href=@{Home} on your HTML element and Yesod will ensure that the value interpolates to a route that exists at compile time).

Haskell libraries often depend on language extensions, whether it is overloaded strings or type families or whatnot... so I think it's strange that Yesod gets picked on for doing the same: taking advantage of the tools provided by GHC to create a better environment for the developer.

[1] http://www.yesodweb.com/book/haskell#template-haskell-14

Re: Web Framework Benchmarks

#192

Post by jalopy »

As a Rails developer and admirer, this is eye-opening. I love the framework (and Ruby especially), but these numbers bear some serious consideration.

30-50x performance difference gets really... real, no? The standard refrain of "throw more hardware at it" must reconcile with the fact that a factor of 30-50x means real dollars for the same amount of load. Is the developer productivity really that much greater?

Re: Web Framework Benchmarks

#193

Post by anuraj »

dkroy wrote: post #23
anuraj wrote: post #16

Earlier quoted context omitted.

If you care about performance, the thinner the framework, the better.

Doesn't matter if you compile it like Facebook had done with their php at one time when they needed to scale.

To some extent yes, but bloated framework issue will remain even if you compile to C++ despite the compiler's best effort optimization.

Re: Web Framework Benchmarks

#194

Post by dmoreno »

Very nice benchmark. As developer of a toy "framework", but powerful http server library, I wanted to check on my project. I did a fast blog entry at http://bit.ly/10l9Smj. I got ~58288.10 for simple json, 8594.39 on db using sqlite, 503.23 for 20 requests.

Anyway for me its more important speed of development than performance on the server. Maybe my servers do not get that many visits.

Re: Web Framework Benchmarks

#195

Post by jholla14 »

goodwink wrote: post #86
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

These could probably be further broken down into micro-frameworks (like Express, Sinatra, Vert.x etc.) and large MVC frameworks (like Play and Rails). Gemini is sort of an outlier that doesn't really fit either category well, but the micro-frameworks have a fairly consistently higher framework optimization index than the large MVC frameworks which is as expected. Express and Sinatra really stand out as widely-used, v…

The play test was written totally incorrectly since it used blocking database calls. Since play is really just a layer on top of Netty it should perform nearly as well if correctly written.

Re: Web Framework Benchmarks

#196

Post by ssmoot »

bhauer wrote: post #118
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.

Maybe the web-server choice (I didn't look to see what that was). But last I looked at it, the Sinatra router really is very naive/awful.

For the size of the framework, that may be the right choice ultimately.

On the other end of the spectrum is Rails, who've written their own Regexp engine for routing basically. It seems to be generally quite a bit faster.

All major Ruby frameworks have just awful routers though really.

Re: Web Framework Benchmarks

#197

Post by plainOldText »

How can you write a web framework benchmark and not include some of the non mainstream languages with probably the most performant frameworks like Erlang (Cowboy, Mochiweb), Haskell (Yesod, Snap Framework)? That's just wrong; anyway.

Re: Web Framework Benchmarks

#198

Post by jholla14 »

kainsavage wrote: post #64
neya wrote: post #53

How about Lift? Btw, the play framework you tested is Java or Scala based? Either way, I'm shocked to see Play perform so slow comparatively. Although it's easily 10x faster than rails on most tests, I'm shocked to see Node.js faster than Play! (by 2x in most cases) Wow!! Maybe Node.js critics should start appreciating it after all..

It is probably worth noting that while we strive to make the tests as fair as possible, we followed the official tutorials for each framework when building out the tests but we fully expect there to be small instances where minor tweaks improve a given test. Given that I am no Play expert, it would be of great value to have one who is (and it sounds like you could lend a hand there) to check out the code on the githu…

The problem is that the database queries were done in a blocking fashion. The test essentially blocks the main event loop which is of course going to kill performance.

Re: Web Framework Benchmarks

#199

Post by wyck »

bhauer wrote: post #61
jtreminio wrote: post #60

I would love to contribute a code for a specific PHP framework: Silex. Do you have requirements you'd like to hit?

That would be fantastic. Get in touch with pfalls on Github and he can give you the information. It's fairly simple.

+1 this would be interesting given that there are a lot of PHP frameworks besides cake, namely.

Silex/Symfony2

Yii

Zend

Kohana

Fuel

Laravel

Re: Web Framework Benchmarks

#200

Post by jholla14 »

bilbo0s wrote: post #128
jondot wrote: 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 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 h…

The Play example was totally unfair since it blocks on the database query which will block the underlying event loop and really lower the overall throughput.
Post reply on HN