我们有一个具有9个节点的Elasticsearch集群,具有以下设置:
正如您所看到的,我们在节点上分配了过多的资源,但是在压力测试下,只有一个节点使用它所有可用的搜索线程。正如我提到的,我们有18个核心,根据默认的搜索线程限制,每个节点中有(3* 18 /2)+1 =28个搜索线程。
问题:
我们测试的内容:
Jmeter对搜索服务进行压力测试。测试服务是使用SearchTemplates调用某些Elasticsearch Nest客户端的web服务。



任何想法都会受到赞赏。
发布于 2017-07-09 09:12:25
读一读https://www.elastic.co/guide/en/elasticsearch/client/net-api/current/connection-pooling.html
看起来您使用的是SingleNodeConnectionPool (在使用低仪式ElasticClient时使用的),即在本例中使用var client = new ElasticClient(uri);,所有请求都将发送到一个节点,该节点需要充当此处描述的Coordinator node:
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html
例如,搜索请求在两个阶段执行,由接收客户端请求 - 的节点协调。 在散射阶段,协调节点将请求转发给保存数据的数据节点。每个数据节点在本地执行请求,并将其结果返回给协调节点。在集合阶段,协调节点将每个数据节点的结果缩减为一个全局结果集。 每个节点都是隐式的协调节点。这意味着,将所有三个node.master、node.data和node.ingest都设置为false的节点只能充当协调节点,不能禁用该节点。因此,这样的节点需要有足够的内存和CPU来处理聚集阶段。
对于集群来说,StaticConnectionPool或SniffingConnectionPool将是一个更好的选择。
https://stackoverflow.com/questions/44989577
复制相似问题