我想知道电梯网框架具有高性能和可扩展性的技术原因？我知道它使用scala,它有一个actor库,但根据安装说明,默认配置是jetty.那么它是否使用actor库来扩展？
现在是开箱即用的可扩展性.只需添加额外的服务器和节点,它将自动扩展,它是如何工作的？它可以处理与支持服务器的500000多个并发连接.
我正在尝试为企业级创建一个Web服务框架,它可以胜过那里的内容,并且易于扩展,可配置和可维护.我对扩展的定义只是增加了更多的服务器,你应该能够容纳额外的负载.
谢谢
Lift的可扩展性方法在一台机器中.跨机器扩展是一个更大,更难的主题.简短的回答是:Scala和Lift不做任何事情来帮助或阻碍水平缩放.
就单个机器中的actor而言,Lift实现了更好的可伸缩性,因为单个实例可以处理比大多数其他服务器更多的并发请求.为了解释,我首先要指出经典的每线程请求处理模型中的缺陷.忍受我,这需要一些解释.
典型的框架使用线程来处理页面请求.当客户端连接时,框架会从池中分配一个线程.该线程然后做三件事:它从套接字读取请求; 它做了一些计算(可能涉及到数据库的I/O); 它会在套接字上发送响应.几乎每一步,线程都会在一段时间内阻塞.在读取请求时,它可以在等待网络时阻塞.在进行计算时,它可以阻塞磁盘或网络I/O. 它也可以在等待数据库时阻塞.最后,在发送响应时,它可以阻止客户端缓慢接收数据并填充TCP窗口.总的来说,该主题可能会占用30%-90%的时间.然而,它花费100%的时间用于这一个请求.
JVM在真正减速之前只能支持这么多线程.线程调度,共享内存实体(如连接池和监视器)的争用以及本机操作系统限制都对JVM可以创建的线程数量施加了限制.
好吧,如果JVM的最大线程数受到限制,并且线程数决定了服务器可以处理多少并发请求,那么并发请求的数量将由线程数决定.
(还有其他问题可以施加下限 - 例如GC捶打.线程是一个基本的限制因素,但不是唯一的限制因素!)
提升将线程与请求分离.在电梯中,请求并不会阻碍线程.相反,线程执行操作(如读取请求),然后向actor发送消息.演员是故事的重要组成部分,因为它们是通过"轻量级"线程安排的.线程池用于处理actor中的消息.避免在actor内部阻塞操作很重要,因此这些线程会迅速返回池中.(请注意,此池对应用程序不可见,它是Scala对actor的支持的一部分.)例如,当前在数据库或磁盘I/O上被阻止的请求不会保留请求处理线程.请求处理线程几乎可以立即使用,以接收更多连接.
这种用于从线程解耦请求的方法允许Lift服务器具有比每个请求线程服务器多得多的并发请求.(我还想指出,Grizzly库支持没有actor的类似方法.)更多并发请求意味着单个Lift服务器可以支持比常规Java EE服务器更多的用户.
在mtnyguard
"Scala和Lift不做任何事情来帮助或阻碍水平缩放"
不太对劲.Lift是高度有状态的框架.例如,如果用户请求表单,那么他只能将请求发布到表单来自的同一台机器上,因为表单处理操作保存在服务器状态中.
这实际上是一种阻碍可伸缩性的方式,因为这种行为对于无共享架构是不一致的.
毫无疑问,升力具有很高的性能,但性能和可扩展性是两回事.因此,如果您希望通过提升进行水平扩展,则必须在负载均衡器上定义粘性会话,该会话将在会话期间将用户重定向到同一台计算机.
京公网安备 11010802040832号 | 京ICP备19059560号-6 