new change: all thread-count rename to vertical-count still allow use old key, but when use old key will print warning log, notice it's ambiguous and deprecated, suggest to use new name
在 2019年1月24日星期四，wjm wjm <[email protected]> 写道： > eventloop will not eat all cpus, OS will schedule all the threads. > > yhs0092 <[email protected]> 于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 >> [email protected] >> >> >> On 1/24/2019 09:38，bismy<[email protected]> wrote： >> +1 >> >> >> >> >> ------------------ 原始邮件 ------------------ >> 发件人: "zzzwjm"<[email protected]>; >> 发送时间: 2019年1月24日(星期四) 上午9:30 >> 收件人: "dev"<[email protected]>; >> >> 主题: [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 > >
