diff --git a/doc/PROFILING_CUBE.md b/doc/PROFILING_CUBE.md
index f0ea3ec4736707b7eca280810119cad485a5652b..37f2a1812577465d2d8a3cf4ebe7b670541eb102 100644
--- a/doc/PROFILING_CUBE.md
+++ b/doc/PROFILING_CUBE.md
@@ -34,9 +34,13 @@ I1014 12:57:20.699692    38 ctr_prediction_op.cpp:169] Average 1.12746us/key
 
 ## 说明
 
-影响Paddle Serving访问cube的因素：
+Paddle Serving实例中打印出的访问cube的平响时间，与[cube社区版本性能报告](https://github.com/PaddlePaddle/Serving/blob/develop/cube/doc/performance.md)中报告的性能数值有差别，影响Paddle Serving访问cube的因素：
 
-1) Serving实例所在机器CPU核数
+1) 批量查询每个请求中key的个数
+
+从日志可看到，Paddle Serving接收到CTR预估任务client发送的请求中，平均每个请求批量key的个数为1300，而性能报告中实测的有批量1个key、100个key和1000个key等
+
+2) Serving实例所在机器CPU核数和客户端请求并发数
 
 假设Paddle Serving所在云服务器上CPU核数为4，则Paddle Serving本身默认会启动4个worker线程。在client端发送4个并发情况下，Serving端约为占满4个CPU核。但由于Serving又要启动新的channel/thread来访问cube（采用的是异步模式），这些和Serving本身的server端代码共用bthread资源，就会出现竞争的情况。
 
@@ -51,7 +55,7 @@ I1014 12:57:20.699692    38 ctr_prediction_op.cpp:169] Average 1.12746us/key
 
 可以看到，当并发数等于（和大于）CPU核数时，访问cube的响应时间就会变大。
 
-2) 稀疏参数字典分片数
+3) 稀疏参数字典分片数
 
 假设分片数为N，每次cube访问，都会生成N个channel，每个来对应一个分片的请求，这些channel和Serving内其他工作线程共用bthread资源。但同时，较多的分片数，每个分片参数服务节点上查询的计算量会变小，使得总体响应时间变小。
 
@@ -62,7 +66,7 @@ I1014 12:57:20.699692    38 ctr_prediction_op.cpp:169] Average 1.12746us/key
 1 | 1680
 2 | 1450
 
-3) 网络环境
+4) 网络环境
 
 百度云平台上机器间ping的时延平均为0.3ms - 0.5ms，在batch为1000个key时，平均响应时间为1450us
 
@@ -70,7 +74,7 @@ Paddle Serving发布的[cube社区版本性能报告](https://github.com/PaddleP
 
 两种环境的主要差别在于：
 
-1) 机器间固有的通信延迟 (百度云上位0.3ms-0.5ms，性能报告测试环境0.06ms)
+(1) 机器间固有的通信延迟 (百度云上位0.3ms-0.5ms，性能报告测试环境0.06ms)
 
-2) 字典分片数 (百度云上2个分片，性能报告测试环境10个分片)
+(2) 字典分片数 (百度云上2个分片，性能报告测试环境10个分片)