-
Notifications
You must be signed in to change notification settings - Fork 284
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
brpc耗时操作怎么使用? #108
Comments
@tkec SyncBenchmarkTest里默认ReadTimeoutMillis是100,建议调大一些。 |
@wenweihu86 SyncBenchmarkTest里改为1000超时了,测试没有超时出错。 |
@tkec server仅仅sleep 100ms,client响应时间变成170ms了?是跑一段时间后,稳定在这个数吗?client端可以在Protocol的decodeResponse函数里打印下收到响应的时间点,确认下具体耗时在哪里。 |
@wenweihu86 响应时间还没看,主要关注的是,server的性能大幅下降,只有100多qps,就算增加workthread数量也提高不了太多,这个非常奇怪。这种情况下,brpc访问数据库等耗时情况,是不是会性能也是大幅下降? |
@tkec 因为当前server实现是同步的,每个请求会占住server的线程直到请求被处理完成,所以对于io密集型server可以通过调大server的work线程数来提高并发,比如: |
@wenweihu86 嗯,上面已经加了options.setWorkThreadNum(500),不过qps只增加到不到200,所以这里是觉得有问题。 RpcServerTest中增加的代码: EchoServiceImpl中增加的代码,在return之前:
SyncBenchmarkTest中修改的代码,启动命令 threadNum=20:
日志: |
@tkec client端线程数设置跟server一样大试试。 |
@wenweihu86 RpcClientOptions中增加了 |
@tkec 我没表述清楚,不好意思。是把传给SyncBenchmarkTest命令行参数设置大一些 |
@wenweihu86 SyncBenchmarkTest命令行的threadNum调大,就全部超时了,因为本来就是因为RpcServer处理不行,而不是客户端处理不过来,调大RpcClient的threadNum,那么就是更多的请求到sever了,threadNum=20时,还没有超时,只是qps非常小,threadNum=500时,基本都超时了。 |
@tkec 这跟我本地测试的结果不太一样。我本地测试时,client调成跟server线程一样大时,并发能提高很多。 |
@wenweihu86 没太明白client调成和server线程一样大是什么意思,server是只有一个server,内部是work线程,client是SyncBenchmarkTest的启动threadNum。请问有哪些详细的改动吗?我按你的修改来试试。 |
SyncBenchmarkTest 启动threadNum表示有threadNum个线程在并发请求server,server得RpcServerOptions.workThreadNum得大于等于threadNum,才能保证每个client请求都在被处理。 |
@wenweihu86 试了下,RpcServerOptions.workThreadNum=500,SyncBenchmarkTest的threadNum=499,qps可以上去了。并且threadNum大于RpcServerOptions.workThreadNum也是正常的,RpcServerOptions.workThreadNum=100,threadNum=500也没问题。因为实现是往线程池里submit,线程池有一个排队。 |
@tkec 了解了。 |
在brpc-java-core-example中执行benchmark的test代码时,将om.baidu.brpc.example.standard.EchoServiceImpl中增加了一段Thread.sleep(100),同时,调大了RpcServerTest中workthreadnum到500,但用SyncBenchmarkTest执行时,qps不到200,用异步client的benchmark,就大量超时。
业务代码是在work threadpool中执行的,有500个线程,100ms的耗时,理论上应该qps在5000左右,为什么实际只有200?有谁可以帮解答下
The text was updated successfully, but these errors were encountered: