52 ms·
190,000 req/seq (micro benchmarks) ... Haskell webserver shootout continues
- to 16y agonice. very nice. just gotta lern haskell now... i guess it would be very useful to serve static pages, for now.
- wingo 16y agoWhat benchmark is this?
- trobertson 16y agoIt looks like they are comparing the new speeds to the first benchmark on this page: http://docs.yesodweb.com/blog/announcing-warp http://docs.yesodweb.com/blog/announcing-warp
- eelco 16y agoThe article mentions the "pong" benchmark which seems to reside here: https://github.com/snoyberg/benchmarks https://github.com/snoyberg/benchmarks. Looking at the code is doesn't do anything besides answering "pong" to any request so it's mostly about testing the overhead of the webserver, not its resilience against high loads.
- antihero 16y agoI may be wrong, but with those benchmarks, the "typical" servers are configured to load the text "PONG" from a file as opposed to the haskell servers that are hard-coded to do it. Surely I/O gives them a massive disadvantage?
- thesz 16y agoYesod does support sendfile: http://hackage.haskell.org/packages/archive/yesod/0.7.1/doc/html/doc-index-S.html http://hackage.haskell.org/packages/archive/yesod/0.7.1/doc/...
- StavrosK 16y agoI don't get what these benchmarks are supposed to do. I mean, it's great that a server takes 5 μs to complete a request, but when my own code takes 10 ms to run, does it really matter? It's 2,000 times slower, it's not like the webserver is the bottleneck...
- eelco 16y agoWell, the faster the webserver, the more time is left for code to run while still having a very responsive website.
- xuhu 16y agoLet's suppose the webserver takes 0ms to run. How much would that help ?
- rudiger 16y agoTo serve a single client, it doesn't matter, but when you're serving more than a few thousand of clients concurrently, there's benefits to a faster web-server. I mean, more concurrent clients on the same hardware, better average/worst-case latency, need for less hardware, less chance of a bottleneck...
- StavrosK 16y agoThat still doesn't make much sense. The gains of sticking with a proven, solid server which you are familiar with surely outweigh the 0.5% speed increase.
- StavrosK 16y agoTo be honest, I'm not really aching for a 0.5% speedup (at best).
- vicaya 16y agohttp://en.wikipedia.org/wiki/Amdahl%27s_law http://en.wikipedia.org/wiki/Amdahl%27s_law
- reirob 16y agoHow do other non-Haskell Web-Servers perform? Is there somewhere a pong benchmark, say for Tomcat, PHP?
- sharmajai 16y agoYes there is, this is a comparison to Snap, while a comparison of Snap to other frameworks including node.js is here: http://snapframework.com/blog/2010/11/17/snap-0.3-benchmarks http://snapframework.com/blog/2010/11/17/snap-0.3-benchmarks
- reirob 16y agoMany thanks for the link! I did not expect PHP and Ruby to be so slow... I am happy to see that Haskell gets better support for Web programming.
- mnutt 16y agoThese benchmarks are misleading. Looking at the github repo, they're comparing a rails app (full MVC, router, etc) against a node app (regex-based routing) to a snap application, which unless I'm missing something about snap actually seems to be two different applications, one to serve files and one that responds "pong". Instead of a rails app they should have benchmarked a rack app.
- jasonkester 16y agoMisleading title. I expected to find a comparison of various webservers. Instead it looks like release notes from somebody's web framework. Incidentally, the proposed HTML syntax in the 2nd half of the article is terrible. Developers have been closing HTML tags for 15 years now, to the point where we've associated little pyramids with correctness. All this syntax does is make all your code look broken all the time.
- dons 16y agoThese are comparisons of various Haskell webservers, running the same micro benchmark, and the given number for Warp is provided. There are links to older benchmarks against servers in other languages. Look for the big graph with different columns for different webservers.