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

211–220 of 241 posts

Re: Web Framework Benchmarks Round 2

#211

Post by mtrimpe »

wyqueshocec wrote: post #176
columbo wrote: post #126

Earlier quoted context omitted.

Oh sure, there are reasons to use an easier/faster-to-develop language, I believe every developer should know a 'hard-and-fast' language and a 'slow-and-easy' language... and know when to use them. 98% of the websites out there could run on python and I doubt we'd see a big performance difference. However, I really don't think there exists a 10x difference developing in Spring. Hell, I don't think there is a 10x diff…

I chose that number because of this anecdote: I worked at a start-up a few years ago. I worked on a PHP-powered website that spoke to a Java-powered (Spring/Hibernate) service layer. The PHP team consisted of one: me. The Java team consisted of over 10 engineers. I outpaced them easily and consistently. In other projects with similar divisions, I've had similar experiences, though not always so dramatic.

I used to be a hired gun that would be called in occasionally to, like you, code circles around bigger teams when deadlines were tight.

Last few years however I decided to stick around with one of my clients for a while and I realized that quite a few of the employees I considered sub-par before were actually pretty decent programmers doing their best to do quality work in a dysfunctional environment.

I've since then learned to really appreciate this quote, which my gut tells applies to your situation as well:

"Never attribute to incompetence that which is adequately explained by bad management."

Re: Web Framework Benchmarks Round 2

#212

Post by spyder »

krg wrote: post #33
diminish wrote: post #30

Earlier quoted context omitted.

Pls could u include some C/C++ web frameworks... comparison with Java, could be interesting..

We're interested in that, too. In progress is the onion http library pull request from davidmoreno: https://github.com/TechEmpower/FrameworkBenchmarks/pull/43 We hope to get more as well.

It would be interesting to see G-WAN too because it seems controversial. http://gwan.ch/

Re: Web Framework Benchmarks Round 2

#213

Post by [deleted] »

bhauer wrote: post #2

This is our first follow up to last week's web framework benchmarks. Since last week, we have received dozens of comments, thoughts, questions, criticisms, and most importantly pull requests. This post shows data collected from a second run on EC2 and i7 hardware that started on Tuesday of this week. A third round with even more community contribution is already underway. Thanks especially to those who have contribut…

[deleted]

Re: Web Framework Benchmarks Round 2

#215

Post by ldh »

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…

> when benchmarking against strongly typed compiled languages, performance concerns become important, even if you have to write ugly code

That seems to defeat the purpose of benchmarking to begin with, or at least makes it less useful for real-world comparison.

Re: Web Framework Benchmarks Round 2

#216

Post by Zak »

jamesaguilar wrote: post #208
Zak wrote: post #198

Earlier quoted context omitted.

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?"

In business terms, what people usually seem to mean is "able to bring in more revenue without having to hire people with skill sets that are rare or difficult to qualify". A software consulting business doesn't scale because it requires hiring programmers; a telephone support business might because it's much easier to hire people who can speak English and follow a script.

Re: Web Framework Benchmarks Round 2

#217

Post by abalone »

bhauer wrote: post #199
abalone wrote: post #195

Interesting that the Play code optimizations had virtually no effect. Almost identical absolute scores between tests. Clearly something heavy's going on within the Play request handling framework to slow things down, not the code we see. I was also surprised at the difference between the Java and Scala play test, since I thought they were supposed to be similar. But it looks like the approaches are quite different. T…

Agreed, and I would certainly like to see the Play tests (both Scala and Java) improve versus what we have measured so far. I would not rule out a configuration glitch in our deployment either. But on that front, I'm really hoping the Play experts can lend a hand. I think we've received a couple tips about the database connection pool size. If the contributions we've seen so far are any indicator, we're going to need…

Thank you Brian for this so much. Really just a fantastic effort and a great contribution to the web dev community.

Re: Web Framework Benchmarks Round 2

#219

Post by coldtea »

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…

>This is a perf benchmark, not a comparison of how concise your code can be (...) performance concerns become important, even if you have to write ugly code

That goes against the notion of benchmarking.

It's about measuring as well as you can how idiomatic code will perform.

Re: Web Framework Benchmarks Round 2

#220

Post by redtuesday »

abalone wrote: post #195

Interesting that the Play code optimizations had virtually no effect. Almost identical absolute scores between tests. Clearly something heavy's going on within the Play request handling framework to slow things down, not the code we see. I was also surprised at the difference between the Java and Scala play test, since I thought they were supposed to be similar. But it looks like the approaches are quite different. T…

I'am certain they didn't test the versions that got merged the last two days (for example the scala version has a working db test now). So we will probably see some improvements in the next version.

EDIT: @json performance difference:

Seems to me like they tested these two versions:

Java - https://github.com/TechEmpower/FrameworkBenchmarks/blob/5203...

Scala (the version with the not working db) - https://github.com/TechEmpower/FrameworkBenchmarks/blob/b89f...

The scala version uses val, which ist like final in java. final enables the JVM to cache this object an run optimizations. So I suspect the object creation only happens once in the scala case, whereas in the java case on every request. I think this is happening here which results in much better performance for the scala version.

But maybe I am wrong and the difference stems only from implementation differences in the controller etc. I'm a php guy and don't know the jvm or scala very well. ;o)

Post reply on HN