Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
PaddlePaddle
Serving
提交
e001cf92
S
Serving
项目概览
PaddlePaddle
/
Serving
大约 1 年 前同步成功
通知
185
Star
833
Fork
253
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
105
列表
看板
标记
里程碑
合并请求
10
Wiki
2
Wiki
分析
仓库
DevOps
项目成员
Pages
S
Serving
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
105
Issue
105
列表
看板
标记
里程碑
合并请求
10
合并请求
10
Pages
分析
分析
仓库分析
DevOps
Wiki
2
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
未验证
提交
e001cf92
编写于
10月 15, 2019
作者:
W
Wang Guibao
提交者:
GitHub
10月 15, 2019
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Update PROFILING_CUBE.md
上级
87f50717
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
10 addition
and
9 deletion
+10
-9
doc/PROFILING_CUBE.md
doc/PROFILING_CUBE.md
+10
-9
未找到文件。
doc/PROFILING_CUBE.md
浏览文件 @
e001cf92
Paddle Serving的CTR预估任务会定期将访问大规模稀疏参数服务
cube的响应时间等统计信息打印出来
。具体的观察方法如下:
Paddle Serving的CTR预估任务会定期将访问大规模稀疏参数服务
的响应时间等统计信息打印出来。用户在k8集群一键部署好分布式训练+Serving方案后,可以在容器内通过CTR预估任务demo观察serving访问稀疏参数服务的响应时间等信息
。具体的观察方法如下:
## 使用CTR预估任务客户端ctr_prediction向Serving发送批量请求
...
...
@@ -36,23 +36,24 @@ I1014 12:57:20.699692 38 ctr_prediction_op.cpp:169] Average 1.12746us/key
影响Paddle Serving访问cube的因素:
1) CPU核数
1)
Serving实例所在机器
CPU核数
假设Paddle Serving所在云服务器上CPU核数为4,则Paddle Serving本身默认会启动4个worker线程。在client端发送4个并发情况下,Serving端约为占满4个CPU核。但由于Serving又要启动新的channel/thread来访问cube(采用的是异步模式),这些和Serving本身的server端代码共用bthread资源,
因此
就会出现竞争的情况。
假设Paddle Serving所在云服务器上CPU核数为4,则Paddle Serving本身默认会启动4个worker线程。在client端发送4个并发情况下,Serving端约为占满4个CPU核。但由于Serving又要启动新的channel/thread来访问cube(采用的是异步模式),这些和Serving本身的server端代码共用bthread资源,就会出现竞争的情况。
以下是在
Serving端不同并发请求数时,访问cube的平均响应时间 (10
00key/req,分片数=1)
以下是在
CTR预估任务Client端向Serving发送不同并发请求数时,访问cube的平均响应时间 (13
00key/req,分片数=1)
线程数 | 访问cube的平均响应时间 (us)
-------|-------
1 | 14
50
1 | 14
65
2 | 1480
3 | 1450
4 | 1905
可以看到,当并发数等于(和大于)CPU核数时,访问cube的响应时间就会变大。
2) 稀疏参数字典分片数
假设分片数为N,每次cube访问,都会生成N个channel,每个来对应一个分片的请求,这些channel和Serving内其他工作线程共用bthread资源。
假设分片数为N,每次cube访问,都会生成N个channel,每个来对应一个分片的请求,这些channel和Serving内其他工作线程共用bthread资源。
但同时,较多的分片数,每个分片参数服务节点上查询的计算量会变小,使得总体响应时间变小。
以下是同一份词典分成1个分片和2个分片,serving端访问cube的平均响应时间 (1300key/req)
...
...
@@ -65,11 +66,11 @@ I1014 12:57:20.699692 38 ctr_prediction_op.cpp:169] Average 1.12746us/key
百度云平台上机器间ping的时延平均为0.3ms - 0.5ms,在batch为1000个key时,平均响应时间为1450us
Paddle Serving发布的
[
cube社区版本性能报告
](
https://github.com/PaddlePaddle/Serving/blob/develop/cube/doc/performance.md
)
中给出的机器间ping时延为0.06ms,在batch为1000个key时,平均响应时间为675us/req
Paddle Serving发布的
[
cube社区版本性能报告
](
https://github.com/PaddlePaddle/Serving/blob/develop/cube/doc/performance.md
)
中
测试环境为裸机部署,
给出的机器间ping时延为0.06ms,在batch为1000个key时,平均响应时间为675us/req
两种环境的主要差别在于:
1) 机器间固有的通信延迟
1) 机器间固有的通信延迟
(百度云上位0.3ms-0.5ms,性能报告测试环境0.06ms)
2) 字典分片数
2) 字典分片数
(百度云上2个分片,性能报告测试环境10个分片)
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录