Skip to content

B
brpc
Commit 729f5df9 authored by gejun's avatar gejun
Browse files
Options

polish case*.md

parent 59d6787a
Hide whitespace changes
Inline Side-by-side
Showing with 33 additions and 155 deletions
docs/cn/case_apicontrol.md
View file @ 729f5df9
......@@ -34,32 +34,17 @@ QA测试结论：通过
| 总线程数 | 193 | 132 | 降低**31.61**% | Baidu RPC版本线程数使用率较低，还可降低 |
| 极限QPS | 3000 | 9000 | 提升**3**倍 | 线下使用Geoconv和Geocoder服务测试 |
**CPU****使用率(%)**Noah监控数据（红色为升级前，蓝色为升级后）
**CPU使用率(%)**（红色为升级前，蓝色为升级后）
![img](../images/apicontrol_compare_1.png)
**内存使用量(KB)**Noah监控数据（红色为升级前，蓝色为升级后）
**内存使用量(KB)**（红色为升级前，蓝色为升级后）
![img](../images/apicontrol_compare_2.png)
****
**鉴权平响(ms)**Noah监控数据（红色为升级前，蓝色为升级后）
**鉴权平响(ms)**（红色为升级前，蓝色为升级后）
![img](../images/apicontrol_compare_3.png)
**转发平响(ms)**Noah监控数据（红色为升级前，蓝色为升级后）
**转发平响(ms)**（红色为升级前，蓝色为升级后）
![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
View file @ 729f5df9
# 背景
[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。
baidu-dsp是联盟基于Ad Exchange和RTB模式的需求方平台，服务大客户、代理的投放产品体系。我们改造了多个模块，均取得了显著的效果。本文只介绍其中关于super-nova-as的改动。super-nova-as是的baidu-dsp的AS，之前使用ub-aserver编写，为了尽量减少改动，我们没有改造整个as，而只是把super-nova-as连接下游（ctr-server、cvr-server、super-nova-bs）的client从ubrpc升级为baidu-rpc。
# 结论
......
docs/cn/case_elf.md
View file @ 729f5df9
# 背景
ELF(Essential/Extreme/Excellent Learning Framework) 框架的目标是为公司内外的大数据应用提供学习/挖掘算法开发支持。 平台主要包括数据迭代处理的框架支持，并行计算过程中的通信支持和用于存储大规模参数的分布式、快速、高可用参数服务器。目前应用于fcr-model，公有云bml，大数据实验室，语音技术部门等等。
# 改造方法
之前是基于[zeromq](http://zeromq.org/)封装的rpc，这次改用baidu-rpc。
ELF(Essential/Extreme/Excellent Learning Framework) 框架为公司内外的大数据应用提供学习/挖掘算法开发支持。 平台主要包括数据迭代处理的框架支持，并行计算过程中的通信支持和用于存储大规模参数的分布式、快速、高可用参数服务器。应用于fcr-model，公有云bml，大数据实验室，语音技术部门等等。之前是基于[zeromq](http://zeromq.org/)封装的rpc，这次改用baidu-rpc。
# 结论
......@@ -14,75 +10,17 @@ ELF(Essential/Extreme/Excellent Learning Framework) 框架的目标是为公司
## 算法总耗时
### 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
ftrl算法: 替换前总耗时2:4:39, 替换后总耗时1:42:48, 提升18%
总时间提升2.5%
ftrl-sync-no-shuffle算法: 替换前总耗时3:20:47, 替换后总耗时3:15:28, 提升2.5%
### Ftrl-sync算法
ftrl-sync算法: 替换前总耗时4:28:47, 替换后总耗时3:45:57, 提升16%
替换前：
任务：[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%
fm-sync算法: 替换前总耗时6:16:37, 替换后总耗时5:21:00, 提升14.6%
## 子任务耗时
### 单个rpc-call
针对ftrl算法
单个rpc-call(针对ftrl算法)
| | Average | Max | Min |
| ---- | --------- | --------- | ---------- |
......@@ -90,9 +28,7 @@ ELF(Essential/Extreme/Excellent Learning Framework) 框架的目标是为公司
| 替换后 | 10.4198ms | 2614.38ms | 0.076416ms |
| 缩短 | 93% | 67% | 70% |
### 单次请求所有rpc-call
针对ftrl算法
单次请求所有rpc-call(针对ftrl算法)
| | Average | Max | Min |
| ---- | -------- | -------- | --------- |
......@@ -100,10 +36,11 @@ ELF(Essential/Extreme/Excellent Learning Framework) 框架的目标是为公司
| 替换后 | 304.878 | 2571.34 | 0 |
| 缩短 | 53.7% | 63.9% | |
## cpu profiling结果
##结论
top 40没有rpc相关函数。
单个rpc-call以及单次请求所有rpc-call的提升非常显著，提升都在50%以上，总任务的耗时除了ftrl-sync-no-shuffle提升不明显外，其余三个算法都有15%左右的提升，现在算法的瓶颈在于对计算逻辑，所以相对单个的rpc的提升没有那么多。
附cpu profiling结果, top 40没有rpc相关函数。
```
Total: 8664 samples
755 8.7% 8.7% 757 8.7% baidu::elf::Partitioner
......
docs/cn/case_iam.md deleted 100644 → 0
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
View file @ 729f5df9
# 背景
这是云平台部开始改造baidu-rpc的试点模块，之前使用了ubrpc。由于使用了mcpack2pb的转换功能，这个模块既能被老的ubrpc client访问，也可以通过protobuf类的协议访问（标准协议，sofa-pbrpc协议等等）。
云平台部把使用ubrpc的模块改造为使用baidu-rpc。由于使用了mcpack2pb的转换功能，这个模块既能被老的ubrpc client访问，也可以通过protobuf类的协议访问（标准协议，sofa-pbrpc协议等等）。
下面是原报告。
# **baidu-rpc改造后的connecter收益明显，可以用较少的机器提供更优质的服务。**
原有使用43台机器（对ubrpc也有富余），baidu-rpc使用3台机器即可（此时访问redis的io达到瓶颈）。当前流量4w qps，支持流量增长，考虑跨机房冗余，避免redis和vip瓶颈，baidu-rpc实际使用8台机器提供服务。
原有使用43台机器（对ubrpc也有富余），baidu-rpc使用3台机器即可（此时访问redis的io达到瓶颈）
baidu-rpc改造后的connecter收益明显，可以用较少的机器提供更优质的服务。收益分3个方面：
当前流量4w qps，支持流量增长，考虑跨机房冗余，避免redis和vip瓶颈，baidu-rpc实际使用8台机器提供服务。
收益分3个方面：
# I 相同配置的机器qps和latency的比较
# 相同配置的机器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的延时，增加微乎其微，提供了较为一致的延时体验**
图中可以看到随着压力的增大：
* baidu-rpc的延时，增加微乎其微，提供了较为一致的延时体验
* ubrpc的延时，快速增大，到了6000~8000qps的时候，出现*queue full*，服务不可用。
**2）ubrpc的延时，快速增大，到了6000~8000qps的时候，出现*queue full*，服务不可用。**
# II 不同配置机器qps和延时的比较：（qps为6500）
| 机器名称 | m1-bccs-module-c03.m1 | tc-bccs-moduled03.tc |
# 不同配置机器qps和延时的比较
qps固定为6500，观察延时。
| 机器名称 | 略 | 略 |
| --------- | ---------------------------------------- | ---------------------------------------- |
| 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） |
......@@ -42,13 +31,11 @@
有此可见：
**1）ubrpc在不同配置下性能表现差异大，在配置较低的机器下表现较差。**
**2）baidu-rpc表现的比ubrpc好，在较低配置的机器上也能有好的表现，因机器不同带来的差异不大。**
* ubrpc在不同配置下性能表现差异大，在配置较低的机器下表现较差。
# III 相同配置机器idle分布的比较
* baidu-rpc表现的比ubrpc好，在较低配置的机器上也能有好的表现，因机器不同带来的差异不大。
机器名：m1-bccs-module-c02.m1（baidu-rpc），m1-bccs-module-c03.m1（ubrpc）
# 相同配置机器idle分布的比较
机器配置：cpu： 24 Intel(R) Xeon(R) CPU E5645 @ 2.40GHz || mem：64G
......@@ -56,10 +43,5 @@
在线上缩容 不断增大压力过程中：
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
* ubrpc cpu idle分布在35%~60%，在55%最集中，最低30%；
* baidu-rpc cpu idle分布在60%~85%，在75%最集中，最低50%； 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