建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块
标签
您还可以添加5个标签
  • 没有搜索到和“关键字”相关的标签
  • 云产品
  • 解决方案
  • 技术领域
  • 通用技术
  • 平台功能
取消

liubao68

发帖: 108粉丝: 94

发消息 + 关注

发表于2019年01月22日 15:55:48 3580 2
直达本楼层的链接
楼主
显示全部楼层
[技术交流] 合理设置servicecomb.rest.server.thread-count的值

很对开发者测试的时候,发现CSE SDK的CPU占用率很多时候只能够到1CPU,这是因为servicecomb.rest.server.thread-count默认值为1。 官网文档将这个配置项含义解释为“服务端线程数”(参考: https://docs.servicecomb.io/java-chassis/zh_CN/build-provider/protocol/rest-over-vertx.html),这个解释其实不怎么准确,容易和event-loop线程数混淆,开发者理解不了,而且提升这个值,CPU的利用率确实会增加,但是通过jstack查看线程数,却不会增加。 


servicecomb.rest.server.thread-count实际上的含义是Vertical的一个概念: vertical instances count。 他是一个非常抽象的概念, 涉及到资源分配和线程绑定关系。比如当值为1的时候,服务端每收到一个请求,就会将请求丢到一个event-loop线程去执行,然后这个绑定关系就确定下来了,不会发生改变。 


单纯的从服务端来看,缺省值为1,而event-loop线程是2 * CPU个,无法修改,那么实际上被使用的event-loop线程只有1个,其他线程都是永远空缺着的。 vertical instances count和操作系统资源是紧密绑定的,对于服务端而言,CPU核数就是资源,因此servicecomb.rest.server.thread-count大于CPU核数就显得毫无意义了。


但是操作系统还有其他的资源和处理,一个进程里面还会处理客户端网络调用, servicecomb.rest.client.thread-count增加,会分配更多的连接资源(句柄)。客户端的一个vertical instance和服务端一样,绑定到一个event-loop线程执行,不会改变。 


Vertx就是利用了极小的线程池(2 * CPU),处理大量的并发请求(网络适配器、CPU、磁盘等)。着也就理解了为什么通常event-loop线程数固定不变,但是单纯看一个点,存在线程池冗余的情况。 总体来看,线程池是被合理的利用到其他地方了。 


举报
分享

分享文章到朋友圈

分享文章到微博

wujimin

发帖: 2粉丝: 0

发消息 + 关注

发表于2019年01月24日 09:14:01
直达本楼层的链接
沙发
显示全部楼层

举个实例说明一下:

假设cpu数为2,则默认会创建4个eventloop


servicecomb.rest.server.thread-count: 3

servicecomb.rest.client.thread-count: 3

servicecomb.highway.server.thread-count: 3

servicecomb. highway.client.thread-count: 3

以上的配置实际会产生下面的效果:

image.png

点赞 评论 引用 举报

wujimin

发帖: 2粉丝: 0

发消息 + 关注

发表于2019年01月24日 09:20:14
直达本楼层的链接
板凳
显示全部楼层

这些verticle仅仅用于收/发网络数据以及执行reactive的业务逻辑

如果是同步逻辑,会调度到业务线程池去执行

点赞 评论 引用 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册