cooper.emiya
cooper.emiya
> 试试[持续下载](https://github.com/apache/brpc/blob/master/docs/cn/http_client.md#%E6%8C%81%E7%BB%AD%E4%B8%8B%E8%BD%BD)看有没有改善？ 抱歉，我们使用的是http直接请求，没有用brpc的client，然后主要问题在于返回1g的数据花了10多秒，根据日志显示应该是请求3秒内rpc方法已经处理完了，也就是返回数据写入socket到返回花了10秒时间，这和我们的网卡带宽和brpc的性能测试貌似不太对得上
> 你好，已经抓包分析，测试是返回一次http请求返回1GB数据， 看起来server在接受请求后0.7秒开始发包返回数据 > 1GB均匀得发送了10s才将数据发送完毕，这和我们网卡的吞吐有点对不上，测试服务器上当时没有其他大量数据往返的网络请求。
> 会不会是网络问题或者client收数据慢了呢？ > > 1. 有没有发生丢包、重传、拥塞控制？ > 2. 分析一下抓包数据，client的接受窗口有没有变化？ > 3. 看一下bvar内置服务rpc_keepwrite_second、rpc_waitepollout_count、rpc_waitepollout_second这三个指标。 1.丢包和重传发生次数较少，但触发了过拥塞控制，接受窗口有变化，如图 但是平时的发送速率依然不高，貌似不是bottleneck 2.请求时rpc_keepwrite_second只在瞬时超过4s，另两个指标如图，但是不太理解什么意思
> rpc_waitepollout_count表示server写socket写到EAGAIN的次数，看起来server不是瓶颈。 client的窗口看着还好没有真正限制到发包过，网卡本身发包慢？