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

shanee
4,201 阅读5分钟

前言

之前介绍了探索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提到一个老外的博客中有提到这个问题的解决方案。

  1. 打开注册表，运行中输入regedit
  2. 定位到一个叫做Parameters的key
  3. 修改里面的MaxUserPort的属性值为66534

这样修改之后，在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。

avatar
文章
阅读
粉丝