thrift客户端复用链接性能掉坑记

1 这次thrift是为了在一个特殊的场景下，我想在客户端来个复用，其实和dubbo在客户端复用连接是一个道理．直接用netty撸一个客户端出来(因为rpc方法只有两个)．

很快撸出来了，能跑．．．爽．

2 嗯，拿出jmeter出来试试调用速度，毕竟不要跟我说单线程能跑就是能跑了．．．．．

  我把业务场景用一个sleep 500-1000毫秒来模拟．

  jmeter的截图没有了，现在写这文章就用个ab的截图(反正是模拟一下并发请求)

 

什么情况？ 10个线程的情况下．．．．业务只是用sleep 500-1000毫秒来代替．．．但是响应时间(rpc开始到收到响应)的时间居然都是5秒以上．．．．这真像单线程在跑．．．．

3 性能问题的查找

　一般来说，性能问题用一些问题还是容易能发现瓶颈在哪里的(但是解决未必很容易)．但是我这次居然醉了．．．．．种种迹像表明方法调用上不存在性能问题．．．．

　上图来看,读写都没有1毫秒

    再看业务调用 (10个worker线程),随意挑一个线程

5８０毫秒．．．

于是问题来了，主要的两个方法读写＋业务的方法加起来都一般没有一秒，在哪里来的响应是5秒．．．．

实在是崩溃

４　有点没有头绪，这事花了不少时间，大概花了一两天．．．．才知道,问题其实是socket读写的方式上，这种模式下．．．

其实走的有点类似请求－响应的模式，所以在读写上反而成了这种复用的瓶颈

来个thrift的server和netty撸的server要socket上的区别

撸的netty的简单化server

目前粗步看了，影响上面的代码应该就是读写的模式上

org.apache.thrift.server.AbstractNonblockingServer.FrameBuffer#read

上面说这是粗略看下代码大概是这样,我们来证明一下

还是走的ab测试,10个线程,100个请求.

先从ab看测试结果:

从发送端来看,100个请求,花了55秒, tps约为2

我们再来看看框架在handRead处理的时间,这个是框架的代码,attach上并打印一下日志看看

来看读的粗略的速度

这里的结果也是大多是一秒读两个.

不过呢,这是针对库的一个简单的监控,用的是字节码attach上去的工具.

上面是用眼睛数,所以太LOW了点.还是统计一下吧,,看看程序统计的结果

10秒统计一次,统计的结果是TPS 是1.7个