brpc耗时操作怎么使用？ about starlight HOT 15 CLOSED

@tkec SyncBenchmarkTest里默认ReadTimeoutMillis是100，建议调大一些。
另外线程数调成cpu核数试试。

from starlight.

@wenweihu86 SyncBenchmarkTest里改为1000超时了，测试没有超时出错。
RpcServer里默认就是cpu核数吧，一开始没改也是一样的结果，结果是：success=119,fail=0,average=170722880ns。
加了options.setWorkThreadNum(500); 结果是success=190,fail=0,average=105487491ns。

from starlight.

@tkec server仅仅sleep 100ms，client响应时间变成170ms了？是跑一段时间后，稳定在这个数吗？client端可以在Protocol的decodeResponse函数里打印下收到响应的时间点，确认下具体耗时在哪里。

from starlight.

@wenweihu86 响应时间还没看，主要关注的是，server的性能大幅下降，只有100多qps，就算增加workthread数量也提高不了太多，这个非常奇怪。这种情况下，brpc访问数据库等耗时情况，是不是会性能也是大幅下降？

from starlight.

@tkec 因为当前server实现是同步的，每个请求会占住server的线程直到请求被处理完成，所以对于io密集型server可以通过调大server的work线程数来提高并发，比如：
RpcServerOptions options = new RpcServerOptions();
options.setWorkThreadNum(100);
RpcServer rpcServer = new RpcServer(8002, options);

from starlight.

@wenweihu86 嗯，上面已经加了options.setWorkThreadNum(500)，不过qps只增加到不到200，所以这里是觉得有问题。

RpcServerTest中增加的代码：
options.setWorkThreadNum(500);

EchoServiceImpl中增加的代码，在return之前：

try {
      Thread.sleep(100);
} catch (InterruptedException e) {
      System.out.println("exception:" + e.getLocalizedMessage());
}

SyncBenchmarkTest中修改的代码，启动命令 threadNum=20：

options.setConnectTimeoutMillis(1000);
options.setWriteTimeoutMillis(1000);
options.setReadTimeoutMillis(1000);

日志：
success=190,fail=0,average=105487491ns

from starlight.

@tkec client端线程数设置跟server一样大试试。

from starlight.

@wenweihu86 RpcClientOptions中增加了options.setWorkThreadNum(500);，结果没有变化，qps还是100+，延迟在170ms。
success=119,fail=0,average=169902295ns

from starlight.

@tkec 我没表述清楚，不好意思。是把传给SyncBenchmarkTest命令行参数设置大一些

from starlight.

@wenweihu86 SyncBenchmarkTest命令行的threadNum调大，就全部超时了，因为本来就是因为RpcServer处理不行，而不是客户端处理不过来，调大RpcClient的threadNum，那么就是更多的请求到sever了，threadNum=20时，还没有超时，只是qps非常小，threadNum=500时，基本都超时了。

from starlight.

@tkec 这跟我本地测试的结果不太一样。我本地测试时，client调成跟server线程一样大时，并发能提高很多。

from starlight.

@wenweihu86 没太明白client调成和server线程一样大是什么意思，server是只有一个server，内部是work线程，client是SyncBenchmarkTest的启动threadNum。请问有哪些详细的改动吗？我按你的修改来试试。

from starlight.

SyncBenchmarkTest 启动threadNum表示有threadNum个线程在并发请求server，server得RpcServerOptions.workThreadNum得大于等于threadNum，才能保证每个client请求都在被处理。

from starlight.

@wenweihu86 试了下，RpcServerOptions.workThreadNum=500，SyncBenchmarkTest的threadNum=499，qps可以上去了。并且threadNum大于RpcServerOptions.workThreadNum也是正常的，RpcServerOptions.workThreadNum=100，threadNum=500也没问题。因为实现是往线程池里submit，线程池有一个排队。
上次超时，是因为客户端的超时时间设置短了，设置是2s，但RpcServerOptions.workThreadNum=10，导致处理时长接近10s，所以客户端超时了，如果把客户端超时时间改大为20s就不会超时了，RpcServerOptions.workThreadNum越大，平响时间越短，最短会接近sleep的100ms时间。

from starlight.

@tkec 了解了。

from starlight.