Re: [discuss] change default settings of sync invocation executor
I agree that current default value of thread pool size is too small, but I'm not sure about the disadvantages of the current fixed thread pool. Do you mean if multiple service instances is deployed on the same machine, a fixed thread pool is not so flexible since the instances cannot clean up some idle business thread? Yours sincerely Yao Haishi yhs0...@163.com On 1/24/2019 10:49，wjm wjm wrote： or default integrate only one ThreadPoolExecutor? because most customers TPS is not so high, no need to do this optimize wjm wjm 于2019年1月24日周四 上午10:35写道： currently we provide a default sync invocation executor: - default integrate two fixed thread pool - thread count for one pool is equals cpu count for most customers, thread count of one pool is too small, and fixed thread pool is not so good, so will change to: - default integrate two ThreadPoolExecutor - support to configure core/max thread count, keepAlive time and max queue size for one pool - default core thread: 25, same to tomcat - default max thread: 100, tomcat is 200, because we have 2 pool, so change to 100 - default keepAlive: 1 minute, same to tomcat - default max queue size: Integer.MAX_VALUE, same to tomcat
Re: [discuss] change default settings of sync invocation executor
or default integrate only one ThreadPoolExecutor? because most customers TPS is not so high, no need to do this optimize wjm wjm 于2019年1月24日周四 上午10:35写道： > currently we provide a default sync invocation executor: > >- default integrate two fixed thread pool >- thread count for one pool is equals cpu count > > for most customers, thread count of one pool is too small, and fixed > thread pool is not so good, so will change to: > >- default integrate two ThreadPoolExecutor >- support to configure core/max thread count, keepAlive time and max >queue size for one pool >- default core thread: 25, same to tomcat >- default max thread: 100, tomcat is 200, because we have 2 pool, so >change to 100 >- default keepAlive: 1 minute, same to tomcat >- default max queue size: Integer.MAX_VALUE, same to tomcat > >
[discuss] change default settings of sync invocation executor
currently we provide a default sync invocation executor: - default integrate two fixed thread pool - thread count for one pool is equals cpu count for most customers, thread count of one pool is too small, and fixed thread pool is not so good, so will change to: - default integrate two ThreadPoolExecutor - support to configure core/max thread count, keepAlive time and max queue size for one pool - default core thread: 25, same to tomcat - default max thread: 100, tomcat is 200, because we have 2 pool, so change to 100 - default keepAlive: 1 minute, same to tomcat - default max queue size: Integer.MAX_VALUE, same to tomcat
Re: [discuss] change default value of verticle instance count
eventloop will not eat all cpus, OS will schedule all the threads. yhs0092 于2019年1月24日周四 上午9:49写道： > Hi, wjm. Thank you for your sharing. > As you say that if CPU count is less than 8, it's suggested that the > thread-count is set to the CPU count. There is still a doubt for me. In the > synchronous mode, since the business logic runs in business thread pool, > i.e. the executor, don't we need to leave some CPU cores for the business ? > > > Yours sincerely > > > Yao Haishi > yhs0...@163.com > > > On 1/24/2019 09:38，bismy wrote： > +1 > > > > > -- 原始邮件 -- > 发件人: "zzzwjm"; > 发送时间: 2019年1月24日(星期四) 上午9:30 > 收件人: "dev"; > > 主题: [discuss] change default value of verticle instance count > > > > currently, we created four type verticle for net send/receive and reactive > business logic: > > - rest client verticle > - rest server verticle > - highway client verticle > - highway server verticle > > instances of them controlled by configurations: > > - servicecomb.rest.server.thread-count > - servicecomb.rest.client.thread-count > - servicecomb.highway.server.thread-count > - servicecomb. highway.client.thread-count > > default value of the configurations are set to 1 all, because framework can > not know what's the best value for them, so we set the conservative value > > these default values makes almost all customers need to optimize > the configuration, it's not so good. > so suggest the default values to be: > > - if cpu count less than 8, then thread-count set to cpu count > - if cpu count equals or big than 8, then thread-count set to 8
Re: [discuss] change default value of verticle instance count
Hi, wjm. Thank you for your sharing. As you say that if CPU count is less than 8, it's suggested that the thread-count is set to the CPU count. There is still a doubt for me. In the synchronous mode, since the business logic runs in business thread pool, i.e. the executor, don't we need to leave some CPU cores for the business ? Yours sincerely Yao Haishi yhs0...@163.com On 1/24/2019 09:38??bismy wrote?? +1 -- -- ??: "zzzwjm"; : 2019??1??24??(??) 9:30 ??: "dev"; : [discuss] change default value of verticle instance count currently, we created four type verticle for net send/receive and reactive business logic: - rest client verticle - rest server verticle - highway client verticle - highway server verticle instances of them controlled by configurations: - servicecomb.rest.server.thread-count - servicecomb.rest.client.thread-count - servicecomb.highway.server.thread-count - servicecomb. highway.client.thread-count default value of the configurations are set to 1 all, because framework can not know what's the best value for them, so we set the conservative value these default values makes almost all customers need to optimize the configuration, it's not so good. so suggest the default values to be: - if cpu count less than 8, then thread-count set to cpu count - if cpu count equals or big than 8, then thread-count set to 8
??????[discuss] change default value of verticle instance count
+1 -- -- ??: "zzzwjm"; : 2019??1??24??(??) 9:30 ??: "dev"; : [discuss] change default value of verticle instance count currently, we created four type verticle for net send/receive and reactive business logic: - rest client verticle - rest server verticle - highway client verticle - highway server verticle instances of them controlled by configurations: - servicecomb.rest.server.thread-count - servicecomb.rest.client.thread-count - servicecomb.highway.server.thread-count - servicecomb. highway.client.thread-count default value of the configurations are set to 1 all, because framework can not know what's the best value for them, so we set the conservative value these default values makes almost all customers need to optimize the configuration, it's not so good. so suggest the default values to be: - if cpu count less than 8, then thread-count set to cpu count - if cpu count equals or big than 8, then thread-count set to 8
[discuss] change default value of verticle instance count
currently, we created four type verticle for net send/receive and reactive business logic: - rest client verticle - rest server verticle - highway client verticle - highway server verticle instances of them controlled by configurations: - servicecomb.rest.server.thread-count - servicecomb.rest.client.thread-count - servicecomb.highway.server.thread-count - servicecomb. highway.client.thread-count default value of the configurations are set to 1 all, because framework can not know what's the best value for them, so we set the conservative value these default values makes almost all customers need to optimize the configuration, it's not so good. so suggest the default values to be: - if cpu count less than 8, then thread-count set to cpu count - if cpu count equals or big than 8, then thread-count set to 8
