Vam*_*bhi 5 haskell happstack yesod haskell-snap-framework
我在Yesod的主页上看过基准测试,但它们主要用于静态文件.Snap网站上的基准测试已经过时了.
我正在尝试将Haskell模块公开为服务.服务器的逻辑是在json中接收函数名和参数,调用haskell函数并再次将输出作为json传递.引用透明性保证了线程安全性以及记忆和缓存功能的能力.
如果我支持大约2k - 5k的并发连接,我将如何实现它？这种方法的可扩展性如何？
我强烈建议根据哪个系统为您提供创建应用程序的最佳工具集,在Warp/Yesod和Snap之间做出选择.Warp和Snap都使用相同的底层GHC I/O管理器,并且都经过高度优化.如果为每个系统编写一个编写良好的应用程序,做任何非平凡的事情,都会显示出显着的性能差距,我会感到惊讶.
你的最后一段有点模糊,但我认为Warp或Snap的基本答案就是编写你的代码,I/O管理器将尽可能地扩展.如果您确实发现并发连接成为瓶颈,您可以考虑尝试使用GHC 7.8(尚未发布,但具有大大改进的I/O管理器)或使用多个服务器的prefork技术.
为Warp和Snap发布的大多数基准测试都基于一个非常简单且非常人为的基准测试,它返回一个静态字符串"pong".这非常适合基准测试Web服务器在解析HTTP请求,构建HTTP响应等方面的效率,但在大多数应用程序中,执行这些操作所花费的时间可以忽略不计.其次,我的猜测是,现在Warp和Snap之间可能出现的任何性能差异都可能在将来减少,因为两台服务器都会继续改进并接近理论极限.此外,我预计两台服务器也将从GHC 7.8的性能改进中获益.
Haskell是通过大量并发连接获得高性能的绝佳选择.Haskell有绿色线程,与大多数其他语言的线程相比,它们非常便宜.这为Haskell Web框架提供了巨大的优势.我们可以为每个连接启动一个新线程,并利用大量精力来优化GHC以获得出色的性能,同时仍保持良好的编程模型.
关于Yesod vs Snap,有两个原因是两者作为单独的项目存在.他们正在从两个完全不同的方向解决Haskell中的Web开发问题.它们都受益于Haskell为您提供的性能,因此您应该根据自己喜欢的方法在它们之间进行选择.以下是一些可以帮助您入门的资源: