代码拉取完成，页面将自动刷新
r31658后，brpc能随机地把一部分请求写入一些文件中，并通过rpc_replay工具回放。目前支持的协议有：baidu_std, hulu_pbrpc, sofa_pbrpc。
先按照Getting Started编译好brpc，再去tools/rpc_replay编译。
在CentOS 6.3上如果出现找不到libssl.so.4的错误，可执行ln -s /usr/lib64/libssl.so.6 libssl.so.4临时解决
brpc通过如下flags打开和控制如何保存请求，包含(R)后缀的flag都可以动态设置。
参数说明：
brpc通过一个bvar::Collector来汇总来自不同线程的被采样请求，不同线程之间没有竞争，开销很小。
写出的内容依次存放在rpc_dump_dir目录下的多个文件内，这个目录默认在./rpc_dump_，其中是程序名。不同程序在同一个目录下同时采样时会写入不同的目录。如果程序启动时rpc_dump_dir已经存在了，目录将被清空。目录中的每个文件以requests.yyyymmdd_hhmmss_uuuuus命名，以保证按时间有序方便查找，比如：
目录下的文件数不超过rpc_dump_max_files，超过后最老的文件被删除从而给新文件腾出位置。
文件是二进制格式，格式与baidu_std协议的二进制格式类似，每个请求的binary layout如下：
"PRPC" (4 bytes magic string)
body_size(4 bytes)
meta_size(4 bytes)
RpcDumpMeta (meta_size bytes)
serialized request (body_size - meta_size bytes, including attachment)
请求间紧密排列。一个文件内的请求数不超过rpc_dump_max_requests_in_one_file。
一个文件可能包含多种协议的请求，如果server被多种协议访问的话。回放时被请求的server也将收到不同协议的请求。
brpc提供了SampleIterator从一个采样目录下的所有文件中依次读取所有的被采样请求，用户可根据需求把serialized request反序列化为protobuf请求，做一些二次开发。
#include <brpc/rpc_dump.h>
...
brpc::SampleIterator it("./rpc_data/rpc_dump/echo_server");
for (brpc::SampledRequest* req = it->Next(); req != NULL; req = it->Next()) {
...
// req->meta的类型是brpc::RpcDumpMeta，定义在src/brpc/rpc_dump.proto
// req->request的类型是butil::IOBuf，对应格式说明中的"serialized request"
// 使用结束后必须delete req。
}
brpc在tools/rpc_replay提供了默认的回放工具。运行方式如下：
主要参数说明：
rpc_replay会默认启动一个仅监控用的dummy server。打开后可查看回放的状况。其中rpc_replay_error是回放失败的次数。
如果你无法打开浏览器，命令行中也会定期打印信息：
2016/01/30-16:19:01 sent:101 success:101 error:0 total_error:0 total_sent:28379
2016/01/30-16:19:02 sent:101 success:101 error:0 total_error:0 total_sent:28480
2016/01/30-16:19:03 sent:101 success:101 error:0 total_error:0 total_sent:28581
2016/01/30-16:19:04 sent:101 success:101 error:0 total_error:0 total_sent:28682
2016/01/30-16:19:05 sent:101 success:101 error:0 total_error:0 total_sent:28783
2016/01/30-16:19:06 sent:101 success:101 error:0 total_error:0 total_sent:28884
2016/01/30-16:19:07 sent:101 success:101 error:0 total_error:0 total_sent:28985
2016/01/30-16:19:08 sent:101 success:101 error:0 total_error:0 total_sent:29086
2016/01/30-16:19:09 sent:101 success:101 error:0 total_error:0 total_sent:29187
2016/01/30-16:19:10 sent:101 success:101 error:0 total_error:0 total_sent:29288
[Latency]
avg 122 us
50% 122 us
70% 135 us
90% 161 us
95% 164 us
97% 166 us
99% 172 us
99.9% 199 us
99.99% 199 us
max 199 us
上方的字段含义应该是自解释的，在此略过。下方是延时信息，第一项"avg"是10秒内的平均延时，最后一项"max"是10秒内的最大延时，其余以百分号结尾的则代表延时分位值，即有左侧这么多比例的请求延时小于右侧的延时（单位微秒）。性能测试需要关注99%之后的长尾区域。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。