Skip to content

Commit

Permalink
polish case*.md
Browse files Browse the repository at this point in the history
  • Loading branch information
gejun committed Sep 5, 2017
1 parent 59d6787 commit 729f5df
Show file tree
Hide file tree
Showing 5 changed files with 31 additions and 153 deletions.
25 changes: 5 additions & 20 deletions docs/cn/case_apicontrol.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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)
6 changes: 1 addition & 5 deletions docs/cn/case_baidu_dsp.md
View file
Original file line number Diff line number Diff line change
@@ -1,10 +1,6 @@
# 背景

[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。

# 结论

Expand Down
83 changes: 10 additions & 73 deletions docs/cn/case_elf.md
View file
Original file line number Diff line number Diff line change
@@ -1,10 +1,6 @@
# 背景

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。

# 结论

Expand All @@ -14,96 +10,37 @@ 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 |
| ---- | --------- | --------- | ---------- |
| 替换前 | 164.946ms | 7938.76ms | 0.249756ms |
| 替换后 | 10.4198ms | 2614.38ms | 0.076416ms |
| 缩短 | 93% | 67% | 70% |

### 单次请求所有rpc-call

针对ftrl算法
单次请求所有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相关函数。
单个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
Expand Down
22 changes: 0 additions & 22 deletions docs/cn/case_iam.md
View file

This file was deleted.

48 changes: 15 additions & 33 deletions docs/cn/case_ubprc.md
View file
Original file line number Diff line number Diff line change
@@ -1,65 +1,47 @@
# 背景

这是云平台部开始改造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） |
| baidu-rpc | 3364.66（us） | 3382.15（us） |

有此可见：

**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

![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的消耗低。**
* ubrpc cpu idle分布在35%~60%，在55%最集中，最低30%；
* baidu-rpc cpu idle分布在60%~85%，在75%最集中，最低50%； baidu-rpc比ubrpc对cpu的消耗低。

0 comments on commit 729f5df

Please sign in to comment.