我们使用的是Glassfish 3.0.1,响应时间很长;对于25％的POST / PUT请求,在5分钟的时间内,在响应回来之前,前端负载均衡器已超时.
我的理论是请求正在排队等待一个可用的线程.
我认为这是因为访问日志显示请求需要几秒钟才能完成,但执行请求的时间比我预期的要晚五分钟.
有没有人有任何建议调试线程池发生了什么？或者最适合他们的设置？
是否需要定期执行线程转储,或者一次转储是否足够？
解决方法
乍一看,这似乎与线程本身几乎没有关系.不知道你的网络设置的其余部分,这里有一些事情我会检查：
>负载平衡器池中是否有死/不响应的节点？这可能导致针对该节点尝试所有请求,直到它们在重定向到另一个节点之前由于超时而失败.
>负载均衡器和Glassfish服务器之间的初始连接是否有问题？这可能是缓慢或不正确的DNS查找(尽管服务器应缓存结果),缺少的代理或一些其他与网络有关的问题.
你检查过这些机器之间的时钟是否同步？这可能会导致日志失去同步. 5分钟是一个很奇怪的超时时间.
如果所有这些都是空的,您可能只是在负载平衡器和Web服务器之间产生阻抗不匹配,您可能需要添加Web服务器来处理负载.负载平衡器应该能够为您提供大量的统计信息,以及如何堆叠.
