一次RPC调用时间都去哪儿了

这个思考从一次撕逼开始,我们给用户组提供了一个JSF(京东自研RPC框架)接口,现象:用户组UMP(京东自研性能监控)监控接口调用超过500ms,我们这边监控max值不超过200ms。翻译一下,具体点就是下面这个描述。

服务端代码执行前后添加监控,最大耗时200ms

调用端调用前后添加监控,最大值500ms

针对此现象,不撕逼,不科学。

但一次RPC调用时间都去哪儿了呢?下面是计算方法。

 

一次正常的RPC调用时间

分析如下:

一次正常的调用统计的耗时主要包括:①调用端RPC框架执行时间 + ②网络发送时间 + ③服务端RPC框架执行时间 + ④服务端业务代码时间。

① 调用端调用的时候RPC框架会首先拦截业务请求,同时将对象序列化,还有就是接收到响应的时候会反序列化;这个时候框架耗时主要与cpu、jvm运行情况相关,序列化耗时主要和传输对象复杂程度相关。

② 网络时间就是数据包在网络传输过程中的时间,包括 请求+响应,耗时主要与数据包大小、网络情况相关。

③ 服务端主要是队列等待时间,请求拦截+反序列、响应的序列化;

如果RPC框架使用了队列,如果配置了可能有一定的等待时间,成熟的RPC框架都会支持队列的方式,不然就是默认线程当队列使用了。

这个时候框架耗时主要与cpu、jvm运行情况相关,序列化耗时主要和传输对象复杂程度相关。

注意如果服务端较忙(线程比较多,然后cpu超过80%),可能从 服务端到接到请求 到 丢到业务线程池给服务端业务代码执行,线程切换也有一定耗时。

④ 服务端业务代码时间才是ump收集的服务端耗时。

另外,如果是一些异常请求(例如服务端线程池已满,客户端超时重试等),其实根本没有打到服务端业务代码,服务端未记录耗时,但是调用端已经记录了这些耗时。所以当时的情况还要看下有无异常情况。

解决方法:

1.首先第一想到的就是要分析网络情况,看是否网络延迟严重,是否有TCP重传

2.分析服务端和调用端的运行情况,看是否压力较大,比如cpu使用率,cpu负载,内存占用大小等。

3.看传输对象是否很大,很复杂,请尽量简单,这个对序列化有很大影响。

4.如果服务端有队列,试着减少队列,或者改为固定线程池,线程特别多,可以试试减少线程大小。

5.控制cpu不要太高,尽量不超80%,不行该扩容就扩容。另外我觉得大部分业务都是I/0密集型,并非计算密集型,这里有个公式,核数*7,比如4C的容器,那么2.8%的使用率应该就很高了。达到80%的时候一定有问题了,要么线程阻塞,要么就赶紧扩容吧。

6.有可能的话,可以以单次耗时为准,查看下单次耗时的差距,从而看看是否是某些参数的请求导致耗时比较长。

7.看看服务端是否有full gc,你懂的。STW。如果频繁yong gc也不是好事儿,无论yong还是full都会STW,只是耗时长短问题。

8.排除了以上种种,还没有定位到原因,那么就需要尝试如下方法了:可在服务端通过tcpdump抓包,用wireshark分析rpc请求在服务端耗时,定位是服务端还是调用端耗时长,然后进一步确定原因。不过这一步,往往需要运维人员配合操作。

以后,请谨慎撕逼。

转载请标明出处,并附上原文链接。尊重创作。

喜欢的最好方式是点击 关注

转载于:https://my.oschina.net/wangxindong/blog/1475403

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值