我在 Yesod 的主页上看到过基准测试，但它们主要针对静态文件。而且 Snap 网站上的基准测试已经过时了。
我正在尝试将 Haskell 模块公开为服务。服务器的逻辑是接收 JSON 格式的函数名称和参数，调用 Haskell 函数并再次以 JSON 形式传递输出。引用透明性保证了线程安全以及内存和缓存函数的能力。
如果我要支持 2k - 5k 数量级的并发连接，我将如何实现它？这种方法的可扩展性如何？
最佳答案
我强烈建议在 Warp/Yesod 和 Snap 之间进行选择，具体取决于哪个系统为您提供了用于创建应用程序的最佳工具集。 Warp 和 Snap 都使用相同的底层 GHC I/O 管理器，并且都经过高度优化。如果为每个系统编写良好的应用程序，执行任何重要的操作，却显示出显着的性能差距，我会感到惊讶。
你的最后一段有点含糊，但我认为 Warp 或 Snap 的基本答案就是只编写你的代码，I/O 管理器将尽可能地扩展。如果您确实发现并发连接是瓶颈，您可以考虑尝试预 fork 技术，使用 GHC 7.8 (尚未发布，但有很大改进的 I/O 管理器)，或使用多个服务器.
关于haskell - 对于高性能应用服务器，我应该选择Yesod的Warp和snap-server中的哪一个？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18593399/