您能否解释一下在各种servlet实现中实现的两种方法:
每个connection
以上两种策略中哪一种的可扩展性更好?为什么?
发布于 2013-03-05 19:52:12
以上两种策略中哪一种的可扩展性更好?为什么?
每请求线程数比每连接线程数可伸缩性更好。
Java线程是相当昂贵的,通常每个线程使用1Mb的内存段,无论它们是活动的还是空闲的。如果您为每个连接提供自己的线程,则该线程通常会在对该连接的连续请求之间处于空闲状态。最终,框架需要要么停止接受新连接(因为它不能创建更多线程),要么开始断开旧连接(这会在用户醒来时导致连接混乱)。
HTTP连接比线程堆栈需要的资源要少得多,尽管由于TCP/IP的工作方式,每个IP地址有64K开放连接的限制。
相比之下,在每个请求的线程模型中,只有在处理请求时才关联线程。这通常意味着服务需要更少的线程来处理相同数量的用户。由于线程使用了大量资源,这意味着服务将具有更高的可伸缩性。
(请注意,每请求一个线程并不意味着框架必须关闭HTTP请求之间的TCP连接...)
话虽如此,当每个请求的处理过程中存在长时间停顿时,每个请求的线程模型并不理想。(当服务使用comet方法时,这尤其不理想,这种方法需要长时间保持应答流的打开。)为了支持这一点,Servlet 3.0规范提供了一种“异步servlet”机制,该机制允许servlet的请求方法暂停其与当前请求线程的关联。这会释放线程去处理另一个请求。
如果web应用程序可以设计为使用“异步”机制,那么它可能比每个请求的线程或每个连接的线程更具伸缩性。
后续
让我们假设一个包含1000张图片的网页。这将导致1001个HTTP请求。此外,让我们假设使用了HTTP持久连接。使用TPR策略,这将导致1001个线程池管理操作(TPMO)。使用TPC策略,这将导致1个TPMO...现在,根据单个TPMO的实际成本,我可以想象TPC可能比TPR扩展得更好的场景。
我认为有一些事情你没有考虑到:
web浏览器面对大量的URL来完成一个页面可能会打开多个connections.
我的感觉是,这些因素可能会超过TPMO为每个连接指定一个线程所节省的成本。
发布于 2013-03-05 15:01:38
HTTP 1.1
-支持persistent connections,这意味着可以使用相同的HTTP连接接收/发送多个请求/响应。因此,为了并行运行使用相同连接接收的那些请求,需要为每个请求创建一个新的Thread
。
HTTP 1.0
-在此版本中,只收到一个使用连接的请求,并且在发送响应后关闭连接。因此,只为一个连接创建了一个线程。
发布于 2013-03-05 18:20:56
Thread per connection
是重用来自multiple requests
(keep-alive)的相同HTTP Connection
的概念。
Thread per request
将为each request
创建一个线程,从一个client
.Server可以创建多个threads
作为每个request
。
https://stackoverflow.com/questions/15217524
复制相似问题