探索ElasticSearch-基准测试BenchMark（五）

之前介绍了 探索ES-对象和嵌套对象（三） 和 探索ES-嵌套对象和父子对象（四） ,今天想来宏观的把握一下 ElasticSearch 的性能到底是怎么样的？

我们可以使用 基准测试 来对 ElasticSearch 的性能进行测试。

基准测试

环境准备

因为暂时没有好的 Linux 服务器，所以只能现在自己的 windows 环境中先测试一把了。

• 机器：Windows10 6核心 16GB内存
• ElasticSearch启动参数：JVM 1GB
• mapping文件:

{
  "mapping": {
    "doc": {
      "properties": {
        "message": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          }
        },
        "postDate": {
          "type": "date"
        },
        "user": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          }
        }
      }
    }
  }
}
复制代码

然后，我们启动在机器中的 ElasticSearch 、 Kibana 和 Jmeter 。其中 Kibana 用来对 ElasticSearch 性能做监控， Jmeter 用来发送 Index 请求，不断发送 Http 请求。

配置Jmeter

创建一个 Http Request 的组件，并配置 ElasticSearch 所需要的 IP 和端口。

注意这个时候，还不能正常发送请求，会提示 text/plain 的 head 不正确。

解决这个问题的方法是在创建一个 HTTP Header Manager 。在 HTTP Header Manager 上面指定 Content-Type 是 application/json 。

虽然在 Kibana 中已经有了对于 ElasticSearch 的监控，但是我们还是可以在 Jmeter 中配置监控 TPS 对应的组件。配置上 Summary Report 和 View Results Tree 。

启动下 Jmeter ，发现可以正常发送 Index 请求， ElasticSearch 中也是正常创建了新的文档。

遇到问题

在初步尝试使用100线程数来压测 ElasticSearch 。

发现在 Summary Report 中提示如下错误信息。

java.net.BindException: Address already in use: connect
复制代码

大概意思是端口已经被使用了。初步分析是由于是当前系统中所开启的线程数过多，导致端口不够用了吧。但是，需要在哪里修改参数呢？

在业界流传着这么一句话

你现在遇到的问题，早在八百年前就有人遇到了。
复制代码

所以，我们去 Google 上面搜索下。发现了 apache-multiple-requests-with-jmeter 这么一篇 StackOverflow 的帖子，这里不得不感叹 StackOverflow 的强大的知识沉淀能力。

然后 stackoverflow 提到一个老外的博客中有提到这个问题的解决方案。

Parameters
MaxUserPort

这样修改之后，在 Windows 上面就可以暂时进行使用 Jmeter 压测了。

虽然，后来我发现继续加大线程数，还是会时不时出现这个问题。在 StackOverflow 上面也建议到还是希望讲 Jmeter 部署在一台 Linux 的机器上面来对其他应用进行压力测试。

100线程

好了，解决了上面这个问题之后，我们开始第一个场景的压力测试。

可以在 Kibana 中的 Index 索引监控模块中看到， Index Rate 大概在300左右。当前有400K的文档数量。总共存放了21.6MB的数量。

观测 ElasticSearch 的节点状态。

发现 CPU 在快速上升。JVM目前来看还是比较平稳的一个状态。

Segment Count 虽然在上下浮动，可以猜测因为数据在不断地进入到 ES 中，不断有新的 Segment 的值被创建，但是 Segment 数量，达到一定的阀值之后， ES 会自动把 Segment 给合并。所以， Segment 的数量会不停地上下浮动。

Latency 总体还是在几毫秒之内返回，说明在这种数量和请求下面， ES 的 Lantency 还是比较平稳的。没有达到 ES 的压力范围内。

500线程

因为很明显，上述线程数量还是没有达到当前 ES 所能够承受的极限范围。所以，尝试将线程数量上升为500。

可以看到与原先200线程的时候比较，500线程时，CPU使用率再次上升。 不过后面考虑到因为在同一台机器上面启动了Jmeter和ElasticSearch，所以很有可能是Jmeter导致的CPU上升是非常有可能的，下次需要将Jmeter防止到另外一台机器上面来测试下ElasticSearch的性能可能会更加好一点，不过这里测试应该问题也不是很大，毕竟CPU使用率才40%都没有达到，远远没有达到CPU的瓶颈。

可以看到 JVM 的使用率随着不断 Index 新的文档，内存在不断地上升。

Index Memory-Lucene 的总内存在不断的上升，但是 Doc Values 基本没有变化，可能是由于

在 Index Memory-Lucene 的提示说明中可以看到 Index Memory-Lucene 是占据了 JVM 的一部分内存的。

那么 Index Memroy-Lucene 的升高是由于什么原因呢？可以在第二张图片中 Lucene Total 和 Term 的曲线基本上是保持一致的间距。可以认为是由于 Term 的升高导致的。

在回到 索引 的监控界面。可以看到 Request Rate 从原来的300tps显著上升到600tps。

1000线程

1000线程下存在两个问题， Jmeter 又开始大量下面这个错误。再次调节注册表字段还是没有效果，估计得将 Jmeter 放置到 Linux 环境中才能彻底解决这个问题了。

java.net.BindException: Address already in use: connect
复制代码

另外一个就是也需要将 Jmeter 对机器CPU的影响降低到一定程度才可以。不然，测试的效果也不一定准确。

不过，目前在上述影响因子没有去掉的情况下，620左右的tps好像已经是极限了。

关于写作

以后这里每天都会写一篇文章，题材不限，内容不限，字数不限。尽量把自己每天的思考都放入其中。

如果这篇文章给你带来了一些帮助，可以动动手指点个赞，顺便关注一波就更好了。

如果上面都没有，那么写下读完之后最想说的话？有效的反馈和你的鼓励是对我最大的帮助。

另外打算把博客给重新捡起来了。欢迎大家来访问吃西瓜。

我是shane。今天是2019年8月31日。百天写作计划的第三十八天，38/100。