
我们在与您类似的情况下遇到了这些情况。通常在高负载下,不容易在测试中复制。尚未解决,但这是我们经历的步骤。
如果是防火墙问题,我们将收到“连接被拒绝”或SocketTimeout异常。
1)您能否在服务器上的访问日志中跟踪这些请求-
它们显示的HTTP状态为200还是404或其他?在我们的例子中,服务器(在本例中为IIS)日志显示客户端关闭了连接而不是服务器。这是一个谜。
更新: 如果客户总是得到一个200,那么服务器实际上已经发回了一些回应,但我怀疑的响应字节大小(如果这是记录在访问日志)
将与正常响应大小的显示出不同的价值 为该请求。
如果显示的响应大小相同,则您有一个(可能不合理)的条件,即服务器 实际上正确响应了, 但客户端未获得响应,因为连接在两者之间终止。
2)网络管理员团队查看了TCP / IP流量,以确定哪个端(或中间路由器)正在终止HTTP / TCP-
IP对话。一旦我们了解了终止连接的一端,便可以查看原因。足够了解的人可以窥探
3)服务器上是否配置/限制了最大数量的请求-这是否限制了您的连接?
4)是否有任何中间负载均衡器可以丢弃请求?
更新:
我们想做的但还没有完成的另一件事是在客户端和服务器之间创建一条静态路由,以减少两者之间的跳数,并确保没有与网络相关的连接断开。参见http://en.wikipedia.org/wiki/Static_routing
5)另一个建议是也设置ConnectTimeout以查看它们是否可以使用更高的值。
更新:
您可能想尝试conn.getErrorStream()
如果连接失败但服务器仍发送有用数据,则返回错误流。如果未连接连接,或者服务器连接时没有错误,或者服务器有错误但没有发送错误数据,则此方法将返回null。
6)也可以尝试间隔5秒在服务器上进行一组线程转储,以查看是否有任何线程在服务器上显示这些传入请求。
更新: 从今天开始,我们学会了解决这个问题,因为在每天的40万个请求中,总计失败率为200-300,这是0.00075%
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)