每个连接的线程与每个请求的线程有什么区别？

Question

能否解释一下在各种servlet实现中实现的两种方法:

1. 每个连接的线程
2. 每个请求的线程

以上两种策略中哪一种更好地扩展？为什么？

Answer 1

以上两种策略中哪一种更好地扩展？为什么？

每个请求的线程比每个线程的线程更好地扩展.

Java线程相当昂贵,通常每个都使用1Mb内存段,无论它们是活动的还是空闲的.如果为每个连接提供自己的线程,则线程通常在连接上的连续请求之间保持空闲.最终,框架需要停止接受新连接(因为它不能创建更多线程)或者开始断开旧连接(如果/当用户醒来时,这会导致连接流失).

HTTP连接所需的资源比线程堆栈少得多,尽管由于TCP/IP的工作方式,每个IP地址的开放连接数限制为64K.

相反,在每个请求的线程模型中,线程仅在处理请求时关联.这通常意味着服务需要更少的线程来处理相同数量的用户.由于线程使用大量资源,这意味着该服务将更具可扩展性.

(请注意,每个请求的线程并不意味着框架必须关闭HTTP请求之间的TCP连接...)

话虽如此,当在每个请求的处理期间存在长暂停时,每请求线程模型并不理想.(当服务使用彗星方法时,它特别不理想,这种方法涉及保持应答流长时间打开.)为了支持这一点,Servlet 3.0规范提供了一种"异步servlet"机制,它允许servlet的请求方法暂停与当前请求线程的关联.这将释放线程以进行另一个请求.

如果Web应用程序可以设计为使用"异步"机制,则它可能比每个请求的线程或每个连接的线程更具可伸缩性.

跟进

让我们假设一个包含1000张图像的网页.这导致1001个HTTP请求.进一步假设使用HTTP持久连接.使用TPR策略,这将导致1001个线程池管理操作(TPMO).使用TPC策略,这将产生1个TPMO ......现在,根据单个TPMO的实际成本,我可以想象TPC可能比TPR更好地扩展的情况.

我认为有些事你没有考虑过:

• Web浏览器面对许多用于获取以完成页面的URL可能会打开多个连接.

• 使用TPC和持久连接,线程必须等待客户端接收响应并发送下一个请求.如果网络延迟很高,则此等待时间可能很长.

• 服务器无法知道何时可以关闭给定(持久)连接.如果浏览器没有关闭它,它可以"逗留",将TPC线程关闭,直到服务器超时连接.

• TPMO开销并不大,尤其是当您将池开销与上下文切换开销分开时.(您需要这样做,因为TPC将在持久连接上产生上下文切换;请参阅上文.)

我的感觉是,这些因素可能超过TPMO节省了一个专用于每个连接的线程.

Answer 2

HTTP 1.1- 支持持久连接,这意味着可以使用相同的HTTP连接接收/发送多个请求/响应.因此,要并行运行使用相同连接接收的Thread请求,将为每个请求创建一个新请求.

HTTP 1.0 - 在此版本中,仅使用连接收到一个请求,并在发送响应后关闭连接.因此,只为一个连接创建了一个线程.