You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@servicecomb.apache.org by GitBox <gi...@apache.org> on 2020/02/25 04:40:03 UTC

[GitHub] [servicecomb-java-chassis] liubao68 edited a comment on issue #1593: 客户端偶现超时,SlowInvocationLogger无法提供有用信息

liubao68 edited a comment on issue #1593: 客户端偶现超时,SlowInvocationLogger无法提供有用信息
URL: https://github.com/apache/servicecomb-java-chassis/issues/1593#issuecomment-590679686
 
 
   增加连接数和vertical-count能够在一定程度上提高性能。如果你不期望增加, 那么就得降低单个请求的处理时间。 平均时延在4.738秒,所有少量请求超时是很大概率发生的事件。需要系统的测试下在不同的并发压力下,系统的吞吐量和时延分布,然后结合一些调优措施提升性能。 问题里面提到在服务重启的过程中偶然发现,有可能是重启的时候,需要重建连接,如果这个时候并发大,就可能导致请求排队,排队就会导致超时,超时会导致连接再次被重建,会出现短暂的恶性循环。 可以看看稳定状况下的平均响应时间是否有改善,确定是否上述问题,也可以看看服务端的性能统计数据,对比分析下。 
   
   ```
     rest.200    0.0      0.000/0.000        asr_service.asrservice.asyncGetAsrResult
                 0.0      0.000/0.000        dlg_center_service_prod.SmurfsDialogApplication.answerV2
                 0.1      4.738/5.435        tts_service_jtest.ttsservice.processTTS
                 0.0      0.000/0.000        gop_service.asrservice.asyncUploadAsrData
                 0.0      0.000/0.000        asr_service.asrservice.asyncUploadAsrData
                 0.0      0.000/0.000        gop_service.asrservice.asyncGetAsrResult
                 0.1      4.738/5.435        (summary)
   ```
   
   小的超时时间设置可能导致上述短暂的恶性状态,可以设置较小的排队队列,及时丢弃已经超时的请求,客户端做好重试。这个是设置小的超时时间比较重要的可靠性保护措施。
   
   
   
   ```

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services