你不会是程序猿吧?

.NET 多线程查询 ES 响应时间太慢,太慢,太慢

Elasticsearch | 作者 Charles | 发布于2017年03月30日 | 阅读数:5455

ES 5.2.2.Net 开多线程调用NEST的API查询ES,线程开的越多,响应时间越慢
PS. 数据量有1.1亿, 单节点,5个分片
每次查询条件不同,两个查询条件(用户ID, 手机号码), 有用的模糊查询手机号码(固定前面,匹配后面 比如:185*,135*)
 
线程数                                              响应时间(查询一次的时间)
10                                                    1秒之内
100                                                  2-8秒 平均4秒
500                                                  17-27秒 平均22秒
1000                                                36-50秒  平均44秒
mappings.png
已邀请:

kennywu76 - Wood

赞同来自:

1. 机器的硬件配置是怎样的? CPU ,memory , 机械磁盘还是SSD,有无raid?
2. 因为只有一个node,所以每次查询实际上是5个shard并发查询,ES的search thread pool大小和cpu核心数有关系。如果cpu比较弱,能够并发的线程数受限。
3. 测试过程中搜索条件不一样,考虑到索引文件本身也比较大(1亿条数据),因此每次搜索基本上都要访问磁盘上的索引文件不同片段,fetch结果的时候也要读取不同的store文件片段。 也就是说无法受益filter cache和os page cache。 这样就比较考验磁盘的IOPS能力。 
4. UserId是否要做范围查询?还是仅仅就是一个ID用来做精确匹配? 如果是ID类型的数据,更合适使用keyword来索引,查找效率比long要好。
5.  Callphone只做前缀查询的话,text类型是多余的,索引成keyword类型就可以了。
 
测试过程中应该在不同并发量下观测服务器的cpu消耗,磁盘IO情况以及JVM heap使用情况,确定硬件瓶颈在哪里。在达到硬件瓶颈的情况下,继续增加并发量平均响应时间增加是很正常的。做压力测试,平均响应时间只是一个指标,你忽略了另外一个指标就是吞吐量,即单位时间完成了多少次查询。
 
ES的索引随着用户查询有个预热的过程,经常用到的索引文件段会被os cache起来,经常用的filter会被缓存起来。如果是线上的高并发查询应用,对响应时间要求苛刻,又难以接受索引预热过程,可以考虑将索引文件预先装载到os page cache,方法参考: https://www.elastic.co/guide/e ... .html  。这有个前提条件,就是每个结点有足够的内存用来缓存索引文件。

要回复问题请先登录注册