Live data from Hacker News

Web Framework Benchmarks Round 4

techempower.com

91–100 of 358 posts

Re: Web Framework Benchmarks Round 4

#91

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 :)

For many systems performance matters. Claiming that there is no difference between Ruby and C is just sticking your head in the sand.

Re: Web Framework Benchmarks Round 4

#92
post #14

Earlier 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.

I'm a fan of Go, but Go is definitely a bit more verbose than Python.

Re: Web Framework Benchmarks Round 4

#93
post #2

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

The requests per second is importanct, but some frameworks seem to get high average throughput but at the expense of a few slow requests.

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.

[1] http://www.infoq.com/presentations/latency-pitfalls

Re: Web Framework Benchmarks Round 4

#94

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…

If you think about it, it matters. Not that I always want the top performer, but definitely wont pick the last few.

Re: Web Framework Benchmarks Round 4

#95
It's very depressing to see Symfony2 at the bottom of these lists. Although there are quite a few performance optimizations that can be done to improve this, there are few excuses for such poor performance by default.

Re: Web Framework Benchmarks Round 4

#99
post #88

How 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)

We use the cluster module to handle multiple workers (https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...), so far we've received feedback that this is a valid approach.

Re: Web Framework Benchmarks Round 4

#100
post #36

Off 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.

When you have a choice of Simple vs Complex (not complicate), Native vs Virtual but comparable in terms of maturity and expressiveness, which one you pick, honestly?
Post reply on HN