I've seen benchmarks on Yesod's homepage, but they are mostly for static files. And the benchmarks on Snap's website are outdated.
I'm trying to expose a Haskell module as a service. The server's logic is to receive the function name and arguments in JSON, invoke the Haskell function and deliver the output again as JSON. The referential transparency guarantees thread safety and the ability to memoize and cache functions.
If I were to support concurrent connections in the order of 2k - 5k, how would I go about implementing it? How scalable can this approach be?
I would highly recommend making the choice between Warp/Yesod and Snap based on which system provides you with the best set of tools for creating your application. Both Warp and Snap are using the same underlying GHC I/O manager, and both are highly optimized. I would be surprised if a well-written application for each system, doing anything non-trivial, showed a significant performance gap.
Your last paragraph is a bit vague, but I think the basic answer for either Warp or Snap is to just write your code, and the I/O manager will scale as well as possible. If you really find concurrent connections to be the bottleneck, you could consider trying out the prefork technique, using GHC 7.8 (not yet released, but has a much improved I/O manager)
, or using multiple servers.
Most of the benchmarks published for Warp and Snap are based on an extremely simple and very contrived benchmark that returns a static string of "pong". This is great for benchmarking how efficient a web server is at parsing HTTP requests, constructing HTTP responses, etc, but in most applications the time spent doing that stuff will be negligible. Secondly, my guess is that any performance differences there may be between Warp and Snap right now are likely to diminish in the future as both servers continue to improve and approach the theoretical limit. Also, I expect that both servers will also benefit significantly from the performance improvements in GHC 7.8.
Haskell is an excellent choice for getting high performance with a large number of concurrent connections. Haskell has green threads which are extremely cheap compared to threads in most other languages. This gives Haskell web frameworks a huge advantage. We can fire off a new thread for every connection and leverage the massive amount of effort that has gone into optimizing GHC to get great performance while still maintaining a nice programming model.
Regarding Yesod vs Snap, there's a reason that the two exist as separate projects. They are approaching the problem of web development in Haskell from two quite different directions. They both benefit from the performance that Haskell gets you, so you should choose between them based on which approach you prefer. Here are some resources to get you started:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With