CXF Web服务随机等待3秒以获取Apache Tomcat响应

Question

我们有一个Java 8应用程序，由Apache服务器后面的Apache Tomcat 8提供服务，该服务器正在使用CXF并行请求多个Web服务。 有时，其中之一会比其余时间持续多3秒（仅应为500毫秒左右）。

我已经激活了CXF调试，现在在CXF内有3秒丢失的地方：

14/03/2018 09:20:49.061 [pool-838-thread-1] DEBUG o.a.cxf.transport.http.HTTPConduit - No Trust Decider for Conduit '{http://ws.webapp.com/}QueryWSImplPort.http-conduit'. An affirmative Trust Decision is assumed. 
14/03/2018 09:20:52.077 [pool-838-thread-1] DEBUG o.a.cxf.transport.http.HTTPConduit - Sending POST Message with Headers to http://172.16.56.10:5050/services/quertServices Conduit :{http://ws.webapp.com/}QueryWSImplPort.http-conduit

如您所见，这两行之间只有三秒钟的时间。 当请求正常时，通常在这两行之间花费0ms。

我一直在研究CXF代码，但对这3秒钟的原因一无所知...

该服务器应用程序（也由我们维护）由另一个Apache服务器后面的另一个Apache Tomcat 6.0.49提供服务。 事实是，服务器的Apache似乎在3秒后收到了请求。

有人可以帮助我吗？

编辑：我们已经监视了服务器的发送/接收程序包，并且似乎客户端的服务器正在按应有的时间发送协商程序包，而服务器在3秒钟后进行了回复。 这些是我们找到的软件包：

481153  11:31:32 14/03/2018 2429.8542795    tomcat6.exe SOLTESTV010     SOLTESTV002     TCP TCP:Flags=CE....S., SrcPort=65160, DstPort=5050, PayloadLen=0, Seq=2858646321, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192  {TCP:5513, IPv4:62}
481686  11:31:35 14/03/2018 2432.8608381    tomcat6.exe SOLTESTV002     SOLTESTV010     TCP TCP:Flags=...A..S., SrcPort=5050, DstPort=65160, PayloadLen=0, Seq=436586023, Ack=2858646322, Win=8192 ( Negotiated scale factor 0x8 ) = 2097152    {TCP:5513, IPv4:62}

481687  11:31:35 14/03/2018 2432.8613607    tomcat6.exe SOLTESTV010     SOLTESTV002     TCP TCP:Flags=...A...., SrcPort=65160, DstPort=5050, PayloadLen=0, Seq=2858646322, Ack=436586024, Win=256 (scale factor 0x8) = 65536    {TCP:5513, IPv4:62}
481688  11:31:35 14/03/2018 2432.8628380    tomcat6.exe SOLTESTV010     SOLTESTV002     HTTP    HTTP:Request, POST /services/consultaServices    {HTTP:5524, TCP:5513, IPv4:62}

因此，似乎服务器的Tomcat是被某事阻塞的服务器。 有什么线索吗？

编辑2：

尽管昨天发生了这种情况（第一台服务器等待3秒钟等待第二台服务器确认），但这并不是最常见的情况。 通常发生的是我在开始时所描述的（两个CXF日志之间的3秒钟，服务器在3秒钟后收到来自第一个日志的任何请求）。

有时服务器（接收请求的服务器）挂起3秒钟。 例如：

1. 服务器1同时（假定）向服务器2发送5个请求。

2. 服务器2在同一秒内收到其中的4个，并开始处理它们。

3. 服务器2在30毫秒内完成了这4个请求中的2个，并回复了服务器1。

4. 在同一时间或多或少，应用程序日志中未注册任何内容。

5. 三秒钟后，将再次注册日志，服务器完成处理剩余的2个请求。 因此，尽管过程本身仅约几毫秒，但是response_time-request_time为3秒零几毫秒。

6. 同时，剩余的请求（已发送的5个请求中的最后一个）在网络监视器中注册，并由应用程序在几毫秒内处理。 但是，全局处理时间不超过3s，因为它在发送后已到达服务器3秒。

因此，在过程的中间有一个陷阱。 在挂起之前成功处理了2个请求，并在短短的一秒钟之内回复了请求。 其他2个请求持续了更多时间，挂起发生，并以3秒的处理时间结束。 最后一个在挂起发生时到达服务器，因此挂起后它没有进入应用程序。

听起来好像gc阻止了世界……但是我们已经分析了gc.logs，这没有什么问题……还有其他原因吗？

谢谢！

编辑3：

像我上周粘贴的TCP标志一样，我们注意到有很多带有CE标志的数据包，这是TCP拥塞的通知。 我们不是网络专家，但是发现这可能使我们在数据包重发之前延迟3秒……有人可以给我们一些帮助吗？

谢谢。 亲切的问候。

Answer 1

事实是，服务器的Apache似乎在3秒后收到了请求。

您如何解决？ 如果您查看的是Apache日志，那么时间戳可能会误导您。

我首先认为您的Tomcat 6只需3秒即可回答，而不是0到500ms，但是从问题和评论来看，情况并非如此。

假设1 ：垃圾收集器

GC以引入延迟而闻名。 通过使用GC详细程度参数突出显示日志中的GC活动。 如果关联太困难，可以将jstat命令与gcutil选项一起使用，并且可以轻松地与Tomcat的日志进行比较。

假设2 ：网络超时

尽管3s是很短的时间（例如，与Windows上的21s TCP默认超时相比），但它可能是超时。 要跟踪超时，可以使用netstat命令。 使用netstat -an ，查找SYN_SENT连接，使用netstat -s查找错误计数器。 请检查这个有罪的网络服务调用者中是否有任何必须解析或访问的网络资源。

Answer 2

最后，这是由我们在查看TCP标志时发现的网络拥塞引起的。 我们的网络管理员一直在研究问题，试图减少拥塞，减少重新传输的超时。