Tomcat 6响应编写
我正在观察 tomcat 服务器的奇怪行为，似乎 tomcat 没有足够快地向客户端写入响应。这是我所看到的：
当在我的 tomcat 服务器上同时发出大约 200 个请求时，我的应用程序日志显示我的 servlet 的 doGet() 在大约 500 毫秒内完成了请求的处理。然而，在客户端，平均响应时间约为 30 秒（这意味着客户端在 30 秒后开始看到 tomcat 的响应）！
有谁知道我的 servlet 处理时间结束与客户端收到响应的时间之间为什么会有这么长的延迟？
我的服务器托管在 Rackspace VM 上。
I am observing strange behavior of my tomcat server, it seems like tomcat is not writing response to the client fast enough. Here is what I am seeing:
When firing aound 200 requests at the same time at my tomcat server, my application logs shows that my servlet's doGet() finishes process the request in about 500ms. However, at the client side the average response time is about 30 seconds (which means client start seeing response from tomcat after 30 seconds)!
Does anyone have any idea about how come there are such long delay between the end of my servlet's process time and the time when client receives response?
My server is hosted on Rackspace VM.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
找到了罪魁祸首。我观察到，即使只有很少的请求，托管服务器也使用异常高的 CPU 使用率，因此我将 JConsole 连接到 Tomcat，发现我的所有工作线程都具有很高的阻塞计数......并且始终处于阻塞状态。查看堆栈跟踪，锁定发生在 JAXBContext 实例化期间。进一步挖掘应用程序为每个请求创建 JAXBContext，这相对昂贵。
总之，问题是由每个线程的 JAXBContext 实例化引起的。解决方案是确保每个应用程序创建一次 JAXBContext。
Found the culprit. I observed that the hosting server was using abnormally high CPU usage for even for only few requests, so I attached JConsole to Tomcat and found that all my worker thread has high blocking count... and are constantly in blocking state. Looking at the stack trace the locking happened during JAXBContext instantiation. Digg further, the application creating JAXBContext, which is relatively expensive, for each request.
So in summary, the problem was caused by JAXBContext instantiation per thread. Solution was to ensure JAXBContext is created once per application.