Update PROFILING_CUBE.md

doc/PROFILING_CUBE.md

-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的平均响应时间 (1000key/req，分片数=1)
+以下是在CTR预估任务Client端向Serving发送不同并发请求数时，访问cube的平均响应时间 (1300key/req，分片数=1)
 
 线程数 | 访问cube的平均响应时间 (us)
 -------|-------
-1 | 1450
+1 | 1465
 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个分片)