前言
之前介绍了探索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的key - 修改里面的
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。
