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秒
PS. 数据量有1.1亿， 单节点，5个分片
每次查询条件不同，两个查询条件（用户ID, 手机号码）, 有用的模糊查询手机号码（固定前面，匹配后面 比如：185*,135*）
线程数 响应时间（查询一次的时间）
10 1秒之内
100 2-8秒 平均4秒
500 17-27秒 平均22秒
1000 36-50秒 平均44秒
1 个回复
kennywu76 - Wood
赞同来自:
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 。这有个前提条件，就是每个结点有足够的内存用来缓存索引文件。