服务超时实战分析

开发服务的时候，经常发现客户端超时的情况，但是从服务端的日志来看又都比较正常，下面是我项目中遇到的一些不同的超时情况。

 

业务场景：

      基于一段长文本，划出文本中的内链

 

我主要遇到过如下三种场景的超时

1、客户端query太长

服务对这个query的处理消耗的时间比客户端设置的超时长，导致服务还没有把请求处理完毕，客户端就已经超时断开了

当时调用方反馈了超时情况后，我让他们把超时的query全部拿出来看了下，参数的长度长达几万个字符，而我们这种业务场景下服务对请求的处理时间基本和query长度是成正比的，由于他们设置的超时太短，从而导致超时

 

解决办法是：

       针对不同的业务场景要不同的处理。 

       我们的场景是：  其实调用方大量的请求都是重复的请求，我们对请求处理的结果他们并没有存储，这样导致每次用户访问同一个页面的时候，我们都要重复去计算内链。所以后来调用方做了两件事，第一是提高超时时间，第二对已经计算得到的结果进行存储，减少重复请求，第三对过长的文本进行截断或者分批请求

 

2、服务处理不过来了

调用方是通过nginx来访问的我们的服务，客户端报超时，但是nginx日志和我服务端日志都没有报超时

nginx记录的是它和我服务端通信的一个状态，即使客户端超时主动断开了与nginx的连接，只要nginx设置的