Skip to content

B
brpc
Commit 59d6787a authored by jiangrujie's avatar jiangrujie
Browse files
Options

+ Add docs for cases 

Change-Id: I2dd81eeb41e54ce3d260ec86741ceb445fb03a16
parent c0c94e8d
Hide whitespace changes
Inline Side-by-side
Showing with 334 additions and 0 deletions
docs/cn/case_apicontrol.md 0 → 100644
View file @ 59d6787a
# 进展
| 时间 | 内容 | 说明 |
| ----------- | ------------------------------------- | -------------- |
| 8.11 - 8.28 | 调研 + 研发 + 自测 | 自测性能报告见附件 |
| 9.8 - 9.22 | QA测试 | QA测试报告见附件 |
| 10.8 | 北京机房1台机器上线 | |
| 10.14 | 北京机房1台机器上线 | 修复URL编码问题 |
| 10.19 | 北京机房7/35机器上线杭州和南京各2台机器上线 | 开始小流量上线 |
| 10.22 | 北京机房10/35机器上线杭州机房5/26机器上线南京机房5/19机器上线 | 修复http响应数据压缩问题 |
| 11.3 | 北京机房10/35机器上线 | 修复RPC内存泄露问题 |
| 11.6 | 杭州机房5/26机器上线南京机房5/19机器上线 | 同北京机房版本 |
| 11.9 | 北京机房全流量上线 | |
截止目前，线上服务表现稳定。
# QA测试结论
1. 【性能测试】单机支持最大QPS：**9000+**。可以有效解决原来Hulu rpc中一个慢服务拖垮所有服务的问题。性能很好。
2. 【稳定性测试】长时间压测没问题。
QA测试结论：通过
# 性能提升实时统计
统计时间2015.11.3 15:00 – 2015.11.9 14:30，共**143.5**小时（近6天）不间断运行。北京机房升级前和升级后同机房各6台机器，共**12**台线上机器的Noah监控数据。
| 指标 | 升级**前**均值Hulu RPC | 升级**后**均值Baidu RPC | 收益对比 | 说明 |
| -------- | ----------------- | ------------------ | ------------ | ------------------------ |
| CPU占用率 | 67.35% | 29.28% | 降低**56.53**% | |
| 内存占用 | 327.81MB | 336.91MB | 基本持平 | |
| 鉴权平响(ms) | 0.605 | 0.208 | 降低**65.62**% | |
| 转发平响(ms) | 22.49 | 23.18 | 基本持平 | 依赖后端各个服务的性能 |
| 总线程数 | 193 | 132 | 降低**31.61**% | Baidu RPC版本线程数使用率较低，还可降低 |
| 极限QPS | 3000 | 9000 | 提升**3**倍 | 线下使用Geoconv和Geocoder服务测试 |
**CPU****使用率(%)**Noah监控数据（红色为升级前，蓝色为升级后）
![img](../images/apicontrol_compare_1.png)
**内存使用量(KB)**Noah监控数据（红色为升级前，蓝色为升级后）
![img](../images/apicontrol_compare_2.png)
****
**鉴权平响(ms)**Noah监控数据（红色为升级前，蓝色为升级后）
![img](../images/apicontrol_compare_3.png)
**转发平响(ms)**Noah监控数据（红色为升级前，蓝色为升级后）
![img](../images/apicontrol_compare_4.png)
**总线程数(****个)**Noah监控数据（红色为升级前，蓝色为升级后）
![img](../images/apicontrol_compare_5.png)
\ No newline at end of file
docs/cn/case_baidu_dsp.md 0 → 100644
View file @ 59d6787a
# 背景
[baidu-dsp](http://wiki.baidu.com/pages/viewpage.action?pageId=100940602)是联盟基于Ad Exchange和RTB模式的需求方平台，服务大客户、代理的投放产品体系。
# 改造方法
我们改造了多个模块，均取得了显著的效果。本文只介绍其中关于super-nova-as的改动。super-nova-as是的baidu-dsp的AS，之前使用ub-aserver编写，由于当时(2015.1)属于baidu-rpc推广早期，为了尽量减少改动，我们没有改造整个as，而只是把super-nova-as连接下游（ctr-server、cvr-server、super-nova-bs）的client从ubrpc升级为baidu-rpc。
# 结论
1. as的吞吐量有显著提升（不到1500 -> 2500+）
2. cpu优化：从1500qps 50%cpu_idle提高到2000qps 50% cpu_idle；
3. 超时率改善明显。
# 测试过程
1. 环境：1个as，1个bs，1个ctr，1个cvr；部署情况为：bs单机部署，as+ctr+cvr混布；ctr和cvr为baidu-rpc版本
2. 分别采用1000,1500压力对ubrpc版本的as进行压测，发现1500压力下，as对bs有大量的超时，as到达瓶颈；
3. 分别采用2000,2500压力对baidu-rpc版本的as进行压测，发现2500压力下，as机器的cpu_idle低于30%，as到达瓶颈。baidu-rpc对资源利用充分。
| | ubrpc | baidu-rpc |
| -------- | ---------------------------------------- | ---------------------------------------- |
| 流量 | ![img](../images/baidu_dsp_compare_1.png) | ![img](../images/baidu_dsp_compare_2.png) |
| bs成功率 | ![img](../images/baidu_dsp_compare_3.png) | ![img](../images/baidu_dsp_compare_4.png) |
| cpu_idle | ![img](../images/baidu_dsp_compare_5.png) | ![img](../images/baidu_dsp_compare_6.png) |
| ctr成功率 | ![img](../images/baidu_dsp_compare_7.png) | ![img](../images/baidu_dsp_compare_8.png) |
| cvr成功率 | ![img](../images/baidu_dsp_compare_9.png) | ![img](../images/baidu_dsp_compare_10.png) |
\ No newline at end of file
docs/cn/case_elf.md 0 → 100644
View file @ 59d6787a
# 背景
ELF(Essential/Extreme/Excellent Learning Framework) 框架的目标是为公司内外的大数据应用提供学习/挖掘算法开发支持。 平台主要包括数据迭代处理的框架支持，并行计算过程中的通信支持和用于存储大规模参数的分布式、快速、高可用参数服务器。目前应用于fcr-model，公有云bml，大数据实验室，语音技术部门等等。
# 改造方法
之前是基于[zeromq](http://zeromq.org/)封装的rpc，这次改用baidu-rpc。
# 结论
单个rpc-call以及单次请求所有rpc-call的提升非常显著，延时都缩短了**50%**以上，总训练的耗时除了ftrl-sync-no-shuffle提升不明显外，其余三个算法训练总体性能都有**15%**左右的提升。现在瓶颈在于计算逻辑，所以相对单个的rpc的提升没有那么多。该成果后续会推动凤巢模型训练的上线替换。详细耗时见下节。
# 性能对比报告
## 算法总耗时
### Ftrl算法
替换前：
任务：[37361.nmg01-hpc-mmaster01.nmg01.baidu.com](http://nmg01-hpc-mon01.nmg01.baidu.com:8090/job/i-37361/)
总耗时：2:4:39
替换后：
任务：[24715.nmg01-hpc-imaster01.nmg01.baidu.com](http://nmg01-hpc-controller.nmg01.baidu.com:8090/job/i-24715/)
总耗时：1:42:48
总体时间提升18%
### Ftrl-sync-no-shuffle算法
替换前：
任务：[16520.nmg01-hpc-imaster01.nmg01.baidu.com](http://nmg01-hpc-controller.nmg01.baidu.com:8090/job/i-16520/)
总耗时：3:20:47
替换后：
任务：[24146.nmg01-hpc-imaster01.nmg01.baidu.com](http://nmg01-hpc-controller.nmg01.baidu.com:8090/job/i-24146/)
总耗时：3:15:28
总时间提升2.5%
### Ftrl-sync算法
替换前：
任务：[18404.nmg01-hpc-imaster01.nmg01.baidu.com](http://nmg01-hpc-controller.nmg01.baidu.com:8090/job/i-18404/)
总耗时：4:28:47
替换后
任务：[24718.nmg01-hpc-imaster01.nmg01.baidu.com](http://nmg01-hpc-controller.nmg01.baidu.com:8090/job/i-24718/)
总耗时：3:45:57
总时间提升：16%
### Fm-sync算法
替换前
任务：[16587.nmg01-hpc-imaster01.nmg01.baidu.com](http://nmg01-hpc-controller.nmg01.baidu.com:8090/job/i-16587/)
总耗时：6:16:37
替换后
任务：[24720.nmg01-hpc-imaster01.nmg01.baidu.com](http://nmg01-hpc-controller.nmg01.baidu.com:8090/job/i-24720/)
总耗时：5:21:00
总时间提升14.6%
## 子任务耗时
### 单个rpc-call
针对ftrl算法
| | Average | Max | Min |
| ---- | --------- | --------- | ---------- |
| 替换前 | 164.946ms | 7938.76ms | 0.249756ms |
| 替换后 | 10.4198ms | 2614.38ms | 0.076416ms |
| 缩短 | 93% | 67% | 70% |
### 单次请求所有rpc-call
针对ftrl算法
| | Average | Max | Min |
| ---- | -------- | -------- | --------- |
| 替换前 | 658.08ms | 7123.5ms | 1.88159ms |
| 替换后 | 304.878 | 2571.34 | 0 |
| 缩短 | 53.7% | 63.9% | |
## cpu profiling结果
top 40没有rpc相关函数。
```
Total: 8664 samples
755 8.7% 8.7% 757 8.7% baidu::elf::Partitioner
709 8.2% 16.9% 724 8.4% baidu::elf::GlobalShardWriterClient::local_aggregator::{lambda#1}::operator [clone .part.1341]
655 7.6% 24.5% 655 7.6% boost::detail::lcast_ret_unsigned
582 6.7% 31.2% 642 7.4% baidu::elf::RobinHoodLinkedHashMap
530 6.1% 37.3% 2023 23.4% std::vector
529 6.1% 43.4% 529 6.1% std::binary_search
406 4.7% 48.1% 458 5.3% tc_delete
405 4.7% 52.8% 2454 28.3% baidu::elf::GlobalShardWriterClient
297 3.4% 56.2% 297 3.4% __memcpy_sse2_unaligned
256 3.0% 59.2% 297 3.4% tc_new
198 2.3% 61.5% 853 9.8% std::__introsort_loop
157 1.8% 63.3% 157 1.8% baidu::elf::GrowableArray
152 1.8% 65.0% 177 2.0% calculate_grad
142 1.6% 66.7% 699 8.1% baidu::elf::BlockTableReaderManager
137 1.6% 68.2% 656 7.6% baidu::elf::DefaultWriterServer
127 1.5% 69.7% 127 1.5% _init
122 1.4% 71.1% 582 6.7% __gnu_cxx::__normal_iterator
117 1.4% 72.5% 123 1.4% baidu::elf::GrowableArray::emplace_back
116 1.3% 73.8% 116 1.3% baidu::elf::RobinHoodHashMap::insert
101 1.2% 75.0% 451 5.2% baidu::elf::NoCacheReaderClient
99 1.1% 76.1% 3614 41.7% parse_ins
97 1.1% 77.2% 97 1.1% std::basic_string::_Rep::_M_dispose [clone .part.12]
96 1.1% 78.3% 154 1.8% std::basic_string
91 1.1% 79.4% 246 2.8% boost::algorithm::split_iterator
87 1.0% 80.4% 321 3.7% boost::function2
76 0.9% 81.3% 385 4.4% boost::detail::function::functor_manager
69 0.8% 82.1% 69 0.8% std::locale::~locale
63 0.7% 82.8% 319 3.7% std::__unguarded_linear_insert
58 0.7% 83.5% 2178 25.2% boost::algorithm::split [clone .constprop.2471]
54 0.6% 84.1% 100 1.2% std::vector::_M_emplace_back_aux
49 0.6% 84.7% 49 0.6% boost::algorithm::detail::is_any_ofF
47 0.5% 85.2% 79 0.9% baidu::elf::DefaultReaderServer
41 0.5% 85.7% 41 0.5% std::locale::_S_initialize
39 0.5% 86.1% 677 7.8% boost::detail::function::function_obj_invoker2
39 0.5% 86.6% 39 0.5% memset
39 0.5% 87.0% 39 0.5% std::locale::locale
38 0.4% 87.5% 50 0.6% FTRLAggregator::serialize
36 0.4% 87.9% 67 0.8% tcmalloc::CentralFreeList::ReleaseToSpans
34 0.4% 88.3% 34 0.4% madvise
34 0.4% 88.7% 38 0.4% tcmalloc::CentralFreeList::FetchFromOneSpans
32 0.4% 89.0% 32 0.4% std::__insertion_sort
```
\ No newline at end of file
docs/cn/case_iam.md 0 → 100644
View file @ 59d6787a
# 背景
IAM是[公有云](http://cloud.baidu.com/)的认证服务，不同于内网服务，对外服务的权限是must，每个对公有云的请求都要访问该服务，其性能必须很高。
# 改造方法
1. 替换rpc框架，从hulu-rpc替换到baidu-rpc。
2. 优化rpc回调函数 (包括移除lock, 减少外部IO次数，优化热点函数等)。
# 结论
1. 仅从hulu-rpc替换至baidu-rpc，在rpc回调函数不做任何优化的情况下，qps有25%的涨幅(从8k提升至1w)。
2. 仅替换baidu-rpc后，qps=1w，latency=1850us。
优化rpc回调函数，同时开启超线程，增加工作线程数之后，qps=10w， latency=1730us。
在rpc回调函数性能理想时，baidu-rpc表现出良好的扩展性，多开线程可以线性增加吞吐能力。
# 性能对比报告
| | hulu-rpc | 仅替换baidu-rpc | 优化rpc函数+超线程+增加工作线程数 |
| ------- | -------- | ------------ | ------------------- |
| qps | 8k | 1w | 10w |
| latency | - | 1850us | 1730us |
\ No newline at end of file
docs/cn/case_ubprc.md 0 → 100644
View file @ 59d6787a
# 背景
这是云平台部开始改造baidu-rpc的试点模块，之前使用了ubrpc。由于使用了mcpack2pb的转换功能，这个模块既能被老的ubrpc client访问，也可以通过protobuf类的协议访问（标准协议，sofa-pbrpc协议等等）。
下面是原报告。
# **baidu-rpc改造后的connecter收益明显，可以用较少的机器提供更优质的服务。**
原有使用43台机器（对ubrpc也有富余），baidu-rpc使用3台机器即可（此时访问redis的io达到瓶颈）
当前流量4w qps，支持流量增长，考虑跨机房冗余，避免redis和vip瓶颈，baidu-rpc实际使用8台机器提供服务。
收益分3个方面：
# I 相同配置的机器qps和latency的比较
通过逐渐缩容，不断增加connecter的压力，获得单机qps和latency的对应数据如下：
![img](../images/ubrpc_compare_1.png)
测试数据来自：
机器名称：m1-bccs-module-c02.m1（baidu-rpc），m1-bccs-module-c03.m1（ubrpc）
机器配置：cpu: 24 Intel(R) Xeon(R) CPU E5645 @ 2.40GHz || mem: 64G
混布情况：同机部署了逻辑层2.0/3.0和C逻辑层，均有流量
图中可以看到 **随着压力的增大，qps的提高**
**1）baidu-rpc的延时，增加微乎其微，提供了较为一致的延时体验**
**2）ubrpc的延时，快速增大，到了6000~8000qps的时候，出现*queue full*，服务不可用。**
# II 不同配置机器qps和延时的比较：（qps为6500）
| 机器名称 | m1-bccs-module-c03.m1 | tc-bccs-moduled03.tc |
| --------- | ---------------------------------------- | ---------------------------------------- |
| cpu | 24 Intel(R) Xeon(R) CPU E5645 @ 2.40GHz | 24 Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz |
| ubrpc | 8363.46（us） | 12649.5（us） |
| baidu-rpc | 3364.66（us） | 3382.15（us） |
有此可见：
**1）ubrpc在不同配置下性能表现差异大，在配置较低的机器下表现较差。**
**2）baidu-rpc表现的比ubrpc好，在较低配置的机器上也能有好的表现，因机器不同带来的差异不大。**
# III 相同配置机器idle分布的比较
机器名：m1-bccs-module-c02.m1（baidu-rpc），m1-bccs-module-c03.m1（ubrpc）
机器配置：cpu： 24 Intel(R) Xeon(R) CPU E5645 @ 2.40GHz || mem：64G
![img](../images/ubrpc_compare_2.png)
在线上缩容 不断增大压力过程中：
baidu-rpc cpu idle分布在60%~85%，在75%最集中，最低50%；
ubrpc cpu idle分布在35%~60%，在55%最集中，最低30%；
由此可见：
**1）baidu-rpc比ubrpc对cpu的消耗低。**
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment