用ES进行查询的时候，整体速度是非常快的，但是我们的Indices大小小于内存的情况下：3台node，每个node有128G内存，堆大小31G，剩下的给lucene做缓存；index大小104G，shard 12片。
但是如图，我们的使用相同的查询请求（请求语句一模一样，但是value不一样），查询时间方差非常大。特别是有1%的影响时间在200+ms，在我们的应用场景这是很难接受的。
不知道这有可能是什么样的原因？
但是如图，我们的使用相同的查询请求（请求语句一模一样，但是value不一样），查询时间方差非常大。特别是有1%的影响时间在200+ms，在我们的应用场景这是很难接受的。
不知道这有可能是什么样的原因？
5 个回复
kennywu76 - Wood
赞同来自: rockybean 、wanges
1. 测试是从集群冷启动开始的，还是已经预热过后再做的。
2. 测试的并发线程数量， qps有多高。
3. 测试过程中ES结点的资源消耗情况，cpu usage%， load average， thread pool active/queue/reject等等。
如果集群是从冷启动开始做测试， 数据有个逐步warm up的过程，初始的查询可能因为需要访问磁盘，耗时会比较长(特别是机械磁盘)。
如果测试的并发线程数过高，qps过高，可能压到了集群处理极限， 当search thread全部繁忙的时候，可能会有请求在search queue里排队，增加了部分请求的时延。
kennywu76 - Wood
赞同来自: laoyang360
因为我想到我们线上之前遇到过的一个问题，是关于wildcard查询的，查询的性能刚好就和value的长度有关系。 如果用了wildcard query，特别要注意这一点。
rockybean - Elastic Certified Engineer, ElasticStack Fans，公众号：ElasticTalk
赞同来自:
然后调用下 force_merge 看看合并segment后是否会好转
我之前的确遇到过主副分片查询速度不一致的情况，但没有确认最终原因……
wyl0706 - 90后IT男
赞同来自:
kennywu76 - Wood
赞同来自:
最好是有监控系统，将这些数据图表化，看起来更容易。 比如我们将threads_pool图表化后，看起来这样:
这样比较容易帮忙判别问题。