I really don't like these benchmarks. Its like benchmarking Fizzbuzz or something. Frameworks don't do anything. No one chooses a framework (at least I don't) based on performance. You choose one framework over the other because you like the API and/or language. I myself am a framework author (giotto, a python framework that was not included in these benchmarks). If my framework had been included, I'm sure it would e…
Not sure why this is downvoted so badly, the comment is largely correct. This benchmark is even less useful than alioth's shootout, I'm not sure why there is so much effort put into it :)
Web Framework Benchmarks Round 4
91–100 of 358 posts
Re: Web Framework Benchmarks Round 4
#92Earlier quoted context omitted.
Agreed, but the language is sufficiently (edit) MORE verbose than Python that it is still a valid strategy to write in Python first, and then rewrite in Go for performance..
If go is less verbose, then why write it in a more verbose language first? The reality is, go and python are pretty much even for verbosity, and there is absolutely no benefit to writing your app in python first and then go. You'd be better off writing it in go and then rewriting it in go if you want the benefits of learning from your first attempt.
Re: Web Framework Benchmarks Round 4
#93This is the most recent update to our ongoing project measuring the performance of web application platforms and frameworks. In this round we've received several more community-contributed tests in Perl, PHP, Python, Java, and JavaScript. Go is a comeback champion thanks to changes made by Brad Fitzpatrick [1] and others in the Go community. A new "Fortunes" test was also added (implemented in 17 of the frameworks) t…
Also when measuring latency, average and std dev are only revelent if the distribution is guassian in distrition. Which is unlikely.
Better to show percentile based measurements. Like 90% of all requests served in 5ms, and 99% of requests served in 15ms.
See Gil Tene's talk "How not to measure latency" [1] for more info. Also be sure you are not falling into the "Coordinated Omission" trap where you end up measureing the latency wrong.
Re: Web Framework Benchmarks Round 4
#94I really don't like these benchmarks. Its like benchmarking Fizzbuzz or something. Frameworks don't do anything. No one chooses a framework (at least I don't) based on performance. You choose one framework over the other because you like the API and/or language. I myself am a framework author (giotto, a python framework that was not included in these benchmarks). If my framework had been included, I'm sure it would e…
Re: Web Framework Benchmarks Round 4
#95Re: Web Framework Benchmarks Round 4
#96Since this is multi core test, how many instances of Node are running actually?
Re: Web Framework Benchmarks Round 4
#97Re: Web Framework Benchmarks Round 4
#98Whenever I hear "Java" I also get association "slow". But looking into this list - java web frameworks doing incredible job!
Re: Web Framework Benchmarks Round 4
#99How are multiple cores handled? For example, with node.js, the standard way to scale is to run multiple instances (but according to https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... only one instance is run). I wonder how the results would change if only one or two cores were enabled (using taskset or isolcpus)
Re: Web Framework Benchmarks Round 4
#100Off all the top performers, Go seems to be the only sane choice to write a web app. Moreover it is at the sweet spot; expressive, flexible, simple, super performant, good community etc. I think it is convincing enough for me to give Go a serious look for our new app.
>Off all the top performers, Go seems to be the only sane choice to write a web app How so? There's Clojure, Scala and others perfectly good choices on the list. The max latency for Go is also very high compared to most others.