我在 Yesod 的主页上看到了基准测试，但它们主要是针对静态文件的。Snap 网站上的基准已经过时。
我正在尝试将 Haskell 模块公开为服务。服务器的逻辑是接收 JSON 格式的函数名称和参数，调用 Haskell 函数并再次将输出作为 JSON 传递。引用透明性保证了线程安全以及记忆和缓存函数的能力。
如果我要支持 2k - 5k 的并发连接，我将如何实现它？这种方法的可扩展性如何？
问问题
2446 次
2 回答
7
我强烈建议在 Warp/Yesod 和 Snap 之间做出选择，具体取决于哪个系统为您提供了用于创建应用程序的最佳工具集。Warp 和 Snap 都使用相同的底层 GHC I/O 管理器，并且都经过高度优化。如果为每个系统编写良好的应用程序，做任何不平凡的事情，显示出显着的性能差距，我会感到惊讶。
您的最后一段有点含糊，但我认为 Warp 或 Snap 的基本答案是只编写您的代码，I/O 管理器将尽可能地扩展。如果你真的发现并发连接是瓶颈，你可以考虑尝试 prefork 技术，使用 GHC 7.8 (not yet released, but has a much improved I/O manager)，或者使用多个服务器。
于 2013-09-03T17:57:45.573 回答
5
为 Warp 和 Snap 发布的大多数基准测试都基于一个极其简单且非常人为的基准测试，该基准返回一个静态字符串“pong”。这对于衡量 Web 服务器在解析 HTTP 请求、构建 HTTP 响应等方面的效率非常有用，但在大多数应用程序中，花在这些事情上的时间可以忽略不计。其次，我的猜测是，现在 Warp 和 Snap 之间可能存在的任何性能差异在未来都可能会减少，因为这两个服务器都在不断改进并接近理论极限。此外，我预计这两款服务器也将从 GHC 7.8 的性能改进中受益匪浅。
Haskell 是通过大量并发连接获得高性能的绝佳选择。Haskell 有绿色线程，与大多数其他语言的线程相比，它非常便宜。这给 Haskell Web 框架带来了巨大的优势。我们可以为每个连接启动一个新线程，并利用优化 GHC 所付出的大量努力来获得出色的性能，同时仍然保持良好的编程模型。
关于 Yesod 与 Snap，两者作为独立项目存在是有原因的。他们从两个完全不同的方向来处理 Haskell 中的 Web 开发问题。它们都受益于 Haskell 为您提供的性能，因此您应该根据自己喜欢的方法在它们之间进行选择。以下是一些帮助您入门的资源：
于 2013-09-04T16:40:24.937 回答