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

221–230 of 415 posts

Re: Web Framework Benchmarks

#221

Post by voidlogic »

bhauer wrote: post #90
sergiotapia wrote: post #65

Where is ASP.Net MVC? Odd that you list obscure frameworks like Wicket and leave out one of The Big Four frameworks. (The big four in my book are: ASP.Net MVC, Rails, Django and CakePHP)

We'd love to have ASP.Net MVC included. One minor gotcha is that to do it justice, we'd need to spin up a Windows EC2 instance and figure out how to script that. It's on our to-do list! We did briefly test ASP.Net on Mono (see another comment in this thread) but didn't include it since we didn't believe that qualifies as a "production" grade ASP.Net MVC deployment.

You should include it; Lots of shops are deploying their products on .NET MVC with Mono.

Re: Web Framework Benchmarks

#223

Post by goodwink »

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…

Could you point me at an example of an idiomatic, non-trivial Go REST/JSON API server? I've been trying for a while to find something to read to get a better handle on good patterns and idiomatic Go, but I haven't really come up with anything. I've found some very good examples of much lower-level type stuff, but I think I have a decent handle on that type of Go already. What I really would like is a good example of how people are using the higher level parts of the standard library, particularly net/http etc.

Re: Web Framework Benchmarks

#224

Post by bhauer »

knappador wrote: post #112

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

We aim to do Postgres testing soon. As you can imagine, the feedback from this has been awesome. Looking forward to seeing Django on Postgres.

Re: Web Framework Benchmarks

#225

Post by bhauer »

dmoreno wrote: post #194

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.

Oh this is awesome! Very nice performance for a mobile CPU.

Pull request, maybe? :)

Re: Web Framework Benchmarks

#226

Post by bilbo0s »

jholla14 wrote: post #200
bilbo0s wrote: post #128

Earlier quoted context omitted.

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.

Well... to be fair...

the Vert.x example, as configured, blocks massively as well waiting for mongodb queries.

Re: Web Framework Benchmarks

#227

Post by vanderZwan »

k__ wrote: post #171
vanderZwan wrote: post #160

"Among the many factors to consider when choosing a web development framework, raw performance is easy to objectively measure." Oh really? Then why did Zed write such an angry rant about how you are doing it wrong? http://zedshaw.com/essays/programmer_stats.html Can we please see some standard deviations, at least?

What's wrong with that guy?

It's a pretty serious problem with how we benchmark though.

EDIT: when looking up what I vaguely remembered I somehow managed to come across a similar article that was published just today[1], even though I was referring to an older one[2] which was about microstuttering (basically: a high standard deviation in frame rate). The point still stands - in fact it applies to both cases in somewhat different ways.

To give an example: Crossfire and SLI graphics card setups a few years ago[1]. It turned out that while both gave a similar performance increase in average framerates. Then was it discovered that one of them had a significantly lower minimum framerate than the other. A high minimum framerate is probably more important in shooters than peak performance, but that's not what we've been testing all of these years, is it? That's exactly the problem highlighted in the article by Zed.

I know this is a gaming example, but I'm sure that in user perception of the performance this matters just as much for the responsiveness of webpages.

[1] http://www.tomshardware.com/reviews/graphics-card-benchmarki... [2] http://www.tomshardware.com/reviews/radeon-geforce-stutter-c...

Re: Web Framework Benchmarks

#228

Post by bjterry »

pilgrim689 wrote: post #191
markokocic wrote: post #143

Earlier quoted context omitted.

> 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…

Hugs is now defunct (last release in September 2006, doesn't even support the 2010 language standard), so there is no reason that being GHC-only should be a consideration in selecting a Haskell framework. It's the only real option.

Re: Web Framework Benchmarks

#229

Post by bilbo0s »

pfalls wrote: post #159
bilbo0s wrote: post #128

Earlier quoted context omitted.

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…

for Vert.x, we specified the number of verticals in App.groovy, rather than on the command line, which we think is a valid way to specify it.

OK... I ran the Vert.x test... runs a bit faster here with 4 workers instead of 8. I suspect what is happening there is that at times all 8 cores can be pinned by workers, while responses wait to be sent back on the 8 non workers. But not that big a change in speed actually. One thing more, when you swap in a couchbase persister for the mongo persister it's faster yet. The difference is actually much larger than the difference you get balancing the number of worker vs non worker verticles. Also thinking that swapping gson in for jackson would improve things... but I don't think that those are fair changes. (well... the couchbase may be a fair change)

Also tested Cake just because it had been a while since I have used it... and I couldn't believe it was that much worse than PHP. Your numbers there seem valid though given my test results. That's pretty sad.

Finally, tried to get in a test of your Go stuff. I'm making what I think are some fair changes ... but it did not speed up as much as I thought. In fact, initially it was slower than your test with 1.1.

So after further review... well done sir.

Re: Web Framework Benchmarks

#230

Post by bhauer »

jfim wrote: post #130
eweise wrote: 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.

We've got a bunch of feedback that the Play database test needs to be asynchronous, so we'll make that a priority for our next run. Perhaps I can entice you to submit a pull request to improve the Play configuration?
Post reply on HN