Weibing Wang

This PR has conflicts with master.

保持下游的qps一致试试，比如一个下游的时候3000qps，26个下游的时候3000*26 qps试试。

下游26个节点，是在同一台机器上的吗？

rpc_press是最新版吗？如果不是，建议更新到包含这个PR的版本试试：https://github.com/apache/incubator-brpc/pull/1763

旧版rpc_press的问题是发送qps不稳定，有时瞬间发送大量请求，然后又空闲一段时间没有请求。 我猜测你们线上服务可能也是这种情况。 再加上请求被分散给了26个下游结点，那每个下游可能空闲时间更长，空闲期间线程可能被操作系统挂起，或者内存等资源被换出，再次收到请求时就得重新唤醒，导致长尾耗时变多。

还有可能是tcp_autocorking导致的， 把/proc/sys/net/ipv4/tcp_autocorking的值改成0试试

原始需求是统计一次pv消耗的cpu资源，但仅从bthread层面来统计是不够的。我们可以修改bthread代码来统计一个bthread消耗的cpu，但如何把bthread跟一次pv关联起来是难点。 比如在一次pv的处理过程，server端会有io的bthread、处理请求的bthread，client端会有处理rpc response的bthread。 比如用户在处理请求过程中可能启动bthread/pthread来进行并行处理，或者将任务提交到某个bthread/pthread线程池中处理。 另一种思路可以考虑下：将不同成份的流量路由到不同的实例，然后比较不同实例的cpu消耗，从而进行实验资源的评估。

> **Describe alternatives you've considered (描述你想到的折衷方案)** > bthread_attr_t 增加 fn，再切换时支持统计 看了下百度内部现有的bthread_attr_t自定义fn的方式不太满足这里的需求，因为server端bthread是由框架创建而不是由用户创建的，传不了自定义的bthread_attr_t。 因此，这个需求还需要重新开发。如果只是统计bthread的cpu消耗，可以考虑扩展一下bthread::TaskStatistics，加个cpu消耗的统计项，并且在bthread切换时更新该值。

Related: #1589

百度内部是通过gflag来自定义server prefix的，代码大致如下： ```cpp std::string Server::ServerPrefix() const { if (FLAGS_customized_server_prefix.empty()) { return base::string_printf("%s_%d", g_server_info_prefix, listen_address().port); } else { return FLAGS_customized_server_prefix; } } ``` 可以看下哪种方式更方便一些。