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

Web Framework Benchmarks Round 2

techempower.com

Post reply on HN
Print view View original

201–210 of 241 posts

Re: Web Framework Benchmarks Round 2

#201

Post by don_draper »

msgilligan wrote: post #193
pfg wrote: post #152

Earlier quoted context omitted.

I guess that's one of the big advantages JVM languages have. Using stuff like Spring or Hibernate (like Grails does), you benefit from thousands of person-hours spent on tuning those libraries and you still get native Java performance. Obviously there's a price you have to pay for all the things Grails built on top of Spring/Hibernate (in the benchmark it looks like Grails' performance = Spring / 2), but in general,…

It would be interesting to see the results for Grails 2.2 (which uses Groovy 2 and Invoke Dynamic) One of the nice things about Grails is that you can easily drop down to the Spring and/or JVM level when needed for performance.

Yup. I manage a Grails app where I wanted to speed up performance on a popular part of the app. So I replace the Grails controller with a servlet. I saw a bump in performance.

Re: Web Framework Benchmarks Round 2

#202

Post by chops »

krg wrote: post #138
taeric wrote: post #117

Earlier quoted context omitted.

Instead, find it motivational. :) They are accepting pull requests.

In fact we've already got a pull request that includes Cowboy and Elli: https://github.com/TechEmpower/FrameworkBenchmarks/pull/50 We'll be including this in the next round.

If I can find the time, I'll try to put together one for Nitrogen (http://nitrogenproject.com) as well.

Re: Web Framework Benchmarks Round 2

#203

Post by logic »

thatthatis wrote: post #87

This is still a json API comparison, not a full framework comparison. In the first test it sees how fast frameworks can serialize json and in the second test it sees how fast frameworks can access the database AND serialize json. An inefficient json library and a framework is doomed across all tests. There are a lot of things frameworks do beyond serving json. These benchmarks are presented as representative of broad…

Agreed; for example, in our (in-house) use case, switching a django app from using either stdlib's json or simplejson to using ujson[0] was a significant performance increase when serializing/deserializing large-ish (~100MB) JSON datasets.

[0]: https://pypi.python.org/pypi/ujson

Re: Web Framework Benchmarks Round 2

#204

Post by mightybyte »

pilgrim689 wrote: post #123
saosebastiao wrote: post #68

Yesod disappoints! Unfortunate for how much it is hyped. This is definitely good to know, even if it appears that the Warp server was not used.

That's the first thing I noticed. What was used instead of Warp? I also see that Snap got pulled in a couple days ago, so it will probably get tested in the next round. Should be interesting to see how it fares against Yesod.

The way the benchmark is constructed, it's really more about JSON and DB performance. Snap makes no decisions for you about those things, so the numbers really won't reflect the performance of Snap all that much. I don't have great expectations for the "Snap" code that is in there now because it is not using very fast JSON and DB libraries.

Re: Web Framework Benchmarks Round 2

#205

Post by bhauer »

boundlessdreamz wrote: post #51

This is superb. 1. More sorting options please :) I really want to sort by standard deviation. 2. Also in case of rails and other single threaded frameworks are you spinning up multiple processes? 3. Why is Go not being tested in the Database access tests? 4. Can you test rails with unicorn too?

1. Blame me. I put together the charts and tables. I'll try to get some sorting added for the next round! :)

2. Pat (pfalls) should know the answer to that more definitively, but we are definitely trying to use the CPU cores as fully as possible. I think you'll see some comments by Pat elsewhere in this thread suggesting some things coming in round 3.

3. Good question! Mostly because we haven't had the time to add it. I would really like to see it added, though. If you know Go and can write the code, might I entice you to submit a pull request?

4. I believe that is the plan, yes.

Re: Web Framework Benchmarks Round 2

#206

Post by bhauer »

tantaman wrote: post #100

Does anyone know what on earth is Play! doing that makes it is so slow? I'd like to see Lift in there if you guys do another round.

Regarding Lift: good news, we received a pull request for that earlier this week. Too late for this week's run, but we'll try to get it in next week!

https://github.com/TechEmpower/FrameworkBenchmarks/pull/44

Re: Web Framework Benchmarks Round 2

#207

Post by bhauer »

cheriot wrote: post #74

As one would expect, as more data access is added, the scale of differences between web frameworks goes down. It would be interesting if you added 5 and 10 db query test runs as that starts to get closer to what a functional website would be doing.

Hi Cheriot,

We do in fact have 5 and 10-query runs available in the data. Switch the views to "Data table" or "All samples (line chart)" and you should see the data for 1, 5, 10, 15, and 20 queries per request.

Re: Web Framework Benchmarks Round 2

#208

Post by jamesaguilar »

Zak wrote: post #198
jamesaguilar wrote: post #161

Earlier quoted context omitted.

If budget is finite, performant ~= scalable once you get to the point where you're actually trying to scale.

I think most people these days take scalability to mean the ability to handle more load by adding hardware without changing the architecture. That's quite different from how much load the same hardware can handle (performance).

I dunno, I hear the term "scalable" applied to business decisions all the time. I think it encompasses more than "Is this problem embarrassingly parallelizable?"

Re: Web Framework Benchmarks Round 2

#209

Post by vanderZwan »

just2n wrote: post #184

Once again, the Node examples are wrong. - Unnecessary parsing. - Writing strings instead of buffers (they're copied, they aren't sent as-is). - Using async. It does a lot of really nasty things, most of which break V8 optimization best practices. This is a perf benchmark, not a comparison of how concise your code can be. - Having the main request handler in a gigantic function that will never be properly optimized b…

So do a pull request and create a node.js equivalent of the stripped editions of rails and django. I'm sure they're open to it.

Re: Web Framework Benchmarks Round 2

#210

Post by [deleted] »

cheriot wrote: post #74

As one would expect, as more data access is added, the scale of differences between web frameworks goes down. It would be interesting if you added 5 and 10 db query test runs as that starts to get closer to what a functional website would be doing.

[deleted]
Post reply on HN