请求方报超时的比例大概有4%
他们设置的超时时间是500ms
但是我们统计日志，服务时间超过500ms的日志很少
原因是什么呢？
超时原因分析：
1、请求内容太长
根据请求方超时日志， 大多数query的长度都是1w以上，这些query我手动请求，响应时间的确大于500ms， 在服务端还没有处理完的时候，客户端已经超时断开了
2、等待时间太长
客户端报超时的query，其中有部分日志中记录响应时间其实只有100多毫秒
客户端的整个请求时间包括多个部分： 请求网络延迟、等待被处理、被处理、序列化返回、返回网络延迟
目前“被处理”的时间其实很短，但是客户端还是超时，而因为都是内网访问，那么网络延迟的时间是很短的，那么主要的原因应该是在等待被处理或者序列化返回的时候耗时了
如果要验证是等待被处理耗时太长：只能对时间戳了，看发送请求的时间和开始处理（接收到请求）的时间之间的关系， 但是如果客户端和服务端不是一个机器，那么两个机器的时间本身就不同步的话就不好弄了
日志记录丢失的问题：
发现报超时的这些query，日志中部分query查不到日志
网上资料说：是因为logging不是线程安全的， 当多个进程往同一个日志文件里面写日志的时候可能会出现问题：
每一次往disk写入的IO操作，是以1个block的大小为原子单位的。现在的系统中，一个block一般是4K。也就是说当一次写入的log信息大小不超过4k，那么这条log的纪录就是原子的。如果这条log大小超过了4k，那么这条log纪录就有可能被别的进程所中断。
在这里，原子性是由系统本身提供的。在client层面，并不需要任何的加锁操作。也就是说，当我们打印的log不会超过4k时，我们是可以忽略多进程竞争写一个文件的问题的。
这也许就解释了，为什么有些query日志里面没有打印了： 因为请求方给我发送的超时query的长度基本都在1w个字以上，这很显然超过了4k， 所以在写日志的过程中因为线程不安全的问题而发生了写日志失败
日志丢失问题压测验证：
于是，我手动对这个服务进行了压力测试， 单机压测：
当query内容很短的时候， 无论是1个并发、10个还是20个并发，日志记录一条都没有丢失
当query内容很长，长达1w个字的时候，1个并发情况下，日志没有丢失，10个并发的情况下丢失了一条日志，20个并发的情况下丢失了10条日志
参考地址：