你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
输入关键字进行搜索
搜索:
没有找到相关结果
code4j - coder github: https://github.com/rpgmakervx
赞同来自: rockybean 、laoyang360 、cccthought
laoyang360 - 《一本书讲透Elasticsearch》作者，Elastic认证工程师 [死磕Elasitcsearch]知识星球地址：http://t.cn/RmwM3N9；微信公众号：铭毅天下; 博客：https://elastic.blog.csdn.net
赞同来自:
要回复问题请先登录或注册
2 个回复
code4j - coder github: https://github.com/rpgmakervx
赞同来自: rockybean 、laoyang360 、cccthought
顺着楼上大牛的思路，现有业务场景下，评估一下你的线程池模型是否合理
举个例子：
一个节点假设配置search线程池为16，队列长度为1000， 一个线程处理一个搜索请求处理耗时是20ms，那么一个线程一秒可以处理50个请求。 那么理论上16个线程一秒可以处理900个请求，1000+16的线程队列大小是能够容纳qps为900的业务的（当然这是理论上，没有考虑的线程上下文切换，网络原因，内存GC导致stw等等，所以实际值肯定比这个低）。
线程数我觉得就核数两倍好了，最多2.5倍，太多了cpu上来反而影响效率（这个看实际情况，假设写少读多可以适当平衡这些线程数）
我认为可以参照如下公式得出
queueSize < thread*(1s*1000/cost)
然后我提出我的思考方式，我觉得你应该优化一下你的查询。是不是存在耗时很高的查询请求。
如上面分析的，假设你一个查询耗时200ms，那么你16个线程的处理能力瞬间变成 < 90 req/s，如果还有耗时更高的耗时呢，
可以先优化线程模型，顺便捕捉下慢查询。
laoyang360 - 《一本书讲透Elasticsearch》作者，Elastic认证工程师 [死磕Elasitcsearch]知识星球地址：http://t.cn/RmwM3N9；微信公众号：铭毅天下; 博客：https://elastic.blog.csdn.net
赞同来自:
2线程池和队列大小做下配置优化。