我应该为高性能的应用服务器选择哪一个Yesod的经线和快速服务器？

Question

我在Yesod的主页上看到了一些基准，但它们大多是用于静态文件的。而Snap网站上的基准已经过时了。

我试图将Haskell模块公开为服务。服务器的逻辑是接收JSON中的函数名和参数，调用Haskell函数并以JSON的形式再次传递输出。引用透明性保证线程安全以及记忆和缓存函数的能力。

如果我支持2k - 5k的并发连接，我将如何实现它？这种方法的可伸缩性有多大？

Answer 1

我强烈建议在Warp/Yesod和Snap之间做出选择，基于哪个系统为您提供了创建应用程序的最佳工具集。Warp和Snap都使用相同的底层GHC I/O管理器，而且都是高度优化的。如果为每个系统编写良好的应用程序，做任何不平凡的事情，表现出显著的性能差距，我会感到惊讶。

您的最后一段有点模糊，但我认为，无论是翘曲还是快照，基本的答案都是编写代码，I/O管理器将尽可能地扩展。如果您确实发现并发连接是瓶颈，您可以考虑使用GHC7.8 (not yet released, but has a much improved I/O manager)或使用多个服务器来尝试Pre叉技术。

Answer 2

大多数为Warp和Snap发布的基准都是基于一个非常简单和非常人为的基准，它返回一个静态字符串"pong“。这对于基准测试一个web服务器在解析HTTP请求、构造HTTP响应等方面的效率是很好的，但是在大多数应用程序中，完成这些工作所花费的时间将是微不足道的。第二，我的猜测是，随着两台服务器不断改进和接近理论极限，目前Warp和Snap之间的任何性能差异都有可能减小。此外，我预计这两台服务器也将从GHC 7.8中的性能改进中获益良多。

Haskell是获得高性能和大量并发连接的最佳选择。与大多数其他语言中的线程相比，Haskell有非常便宜的绿色线程。这给Haskell web框架带来了巨大的优势。我们可以为每个连接启动一个新线程，并利用大量的精力来优化GHC以获得很好的性能，同时仍然维护一个很好的编程模型。

关于Yesod和Snap，这两者作为单独的项目存在是有原因的。他们正从两个完全不同的方向来探讨Haskell的网络开发问题。它们都从Haskell获得的性能中获益，因此您应该根据您喜欢的方法在两者之间进行选择。下面是一些让您开始工作的资源：

• 一个StackOverflow问题，有一些很好的答案
• 我非常广义的比较矩阵
• 我写的更详细和客观的比较
• 比较web框架的Haskell wiki页面