Jane
Jane
如果并行地去创建RpcClient的实例的话，会有问题。或者是否可以修改一下RpcClient中对于ExtensionLoaderManager是否初始化完全的判断？
场景是服务启动的时候需要加载多个不同rpc服务的RpcClient，为了提高启动效率采用了并行。所以会并行去new几个RpcClient。现在依靠把LoadAllExtensions放到并行new RpcClient之前解决了这个问题。
您好，我已收到您的邮件！祝好！方子健
> 可以贴点数据出来么？ 客户端耗时（cntl->latency_us()）： **rpc_replay_latency : 59729** rpc_replay_latency_9999 : 112963 rpc_replay_latency_cdf : "click to view" rpc_replay_latency_percentiles : "[68928,72482,112963,112963]" rpc_replay_max_latency : 112963 服务端耗时： rpc_server_6001_xx_service_search_concurrency : 1 rpc_server_6001_xx_service_search_count : 173520 rpc_server_6001_xx_service_search_eps : 0...
> 问下 有对应的0.97版本的耗时数据么 看了一下升级前0.9.7的指标： side avg 95% 99.9% client 85.45 133.5 224.61 server 77.63 121.5 200.61 升级后1.0.5的指标是： side avg 95% 99.9% client 87.23 135.91 225.31 server 96.05 151.71 238.21 由于一些外部依赖可能导致时延的绝对值有波动，但是大小关系还是明确发生改变了
> 暂无计划 好的
> > 本身bthread usage使用率不到一半，CPU/内存负载并不高 > > 这个显示的是一段时间的平均值。有可能瞬时worker usage较高，bthread得不到及时调度，所以出现了一些长尾 我们这边生产集群也有这个现象。 针对大佬说的瞬时并发，我试了一下用rpc_replay设置相同qps减少瞬时值影响，确实可以降低长尾，瞬时并发较高应该是bthread调度长尾的一个原因。但是长尾依旧比较长（bthread_creation_latency平均200us，三九线4500us），大佬还有啥别的想法吗？ 例如client的bthread调度要比server的bthread调度差之类的（因为我们这边没有下游的服务，在bthread_creation_qps相同的情况下，bthread_creation_latency一般都会明显比有下游的服务要好得多，平均几us）。