记一次ES查询性能优化思路

现状：

es集群有很多索引，主要索引有routing优化， 查询耗时平均85毫秒。问我有没有优化空间，这个问题其实我想直接说没有的，但是不搞个所以然很难说服自己和别人。所以决定深入研究一下的。

思路：

首先得找到85毫秒是哪些步骤分摊的？然后一一查看是否有优化空间。

工具：

Profile Api 很好的支持查看query、collect、rewrite的耗时。

took 耗时是指searchtransportaction 开始execute到response创建为止。中间包含以下步骤。
1.request序列化
2.请求网络分发到各个shard
3.请求反序列化
4.执行query和collect。
5.返回结果序列化
6.返回结果传输到服务端。
7.在master合并

实际耗时和took耗时可能不一样，因为实际耗时还要包含客户端的网络传输时间。

具体分析：

根据上述步骤，
1.得到耗时85毫秒，和took基本相似，那么排除客户端jest耗时严重。
2.query和collect基本在总耗时的四分之一，可以确定不是shard耗时问题。冷启动会耗时40多毫秒，说明fielddatacache内存不够。后续可以进一步优化，但是不是本次主要问题。
3.因为使用了routing参数，不存在shard合并。
4.使用排除法，基本可以确定时间耗费在transport网络传输和序列化上面占用四分之三。

优化方法：

1.优化机房网络情况，现实很难，毕竟这个延迟可以接受。
2.减少查询返回的字段数量，可以一箭双雕，解决序列化和网络传输慢的问题。

总结：

1.优化耗时需要对耗时用在哪里，还有es查询有哪些步骤，有深入了解。