add srpc performance report

document/msec/cpp_dev_manual.md

@@ -755,36 +755,3 @@ FileMax=10                          ; 本地日志文件个数，默认10个
 FileSize=1024000				    ; 本地单个日志文件大小，默认10M
 ```
 
-
-## 性能测试
-
-#### 测试环境
-```
-CPU: 4 x Intel(R) Xeon(R) CPU X3320 @ 2.50GHz
-内存: 8 GB
-网卡: 千兆网卡
-业务数据大小：13bytes业务数据
-```
-
-#### 测试用例
-
-使用三台机器做测试，A固定做客户端，B和C做SRPC服务器。A和B属于同一机房，时延0.8毫秒，C为异地机房，A和B和它的时延模拟为100毫秒左右。
-- 用例一 <br/>
-A <--> B : A直接和B通信，裸测Echo的性能。
-- 用例二 <br/>
-A <--> B <--> C : A和B通信，B做中转到C，C做Echo，关注B的性能数据。模拟真实业务场景的性能。
-- 用例三 <br/>
-A <--> B <--> A : A和B通信，B做中转到A，A运行客户端和Echo服务器。和用例二的区别在于，中转服务器不会在IO中有太长的等待时间。
-
-#### 性能数据
-
-| 用例类型 | Client IO线程数 | worker进程数 | qps | 时延(ms) | CPU占用 |
-| --- | --- | --- | --- | --- | --- |
-| 用例一 | 100 | 3 | 8.5万 | 3 | 80% |
-| 用例二 | 10000 | 4 | 6.5万 | 106 | 92% |
-| 用例三 | 100 | 4 | 7.5万 | 6 | 91% |
-
-#### 测试说明
-
-用例一主要的瓶颈在proxy进程，SRPC为单proxy。用例二和用例三，能够保证用很少的进程，完全利用好CPU，而内部的编码都是通过微线程，同步编码，能够达到异步的性能。
-

document/msec/cpp_performance.md

@@ -0,0 +1,59 @@
+## 运行环境
+
+```
+CPU: Intel(R) Xeon(R) CPU X3320  @ 2.50GHz  4核
+内存：8GB
+网卡：千兆网卡
+Client与Server之间PING值：0.854ms
+
+```
+
+## 测试程序
+
+- echo服务<br/>server将请求字符串直接返回
+- 延时echo服务<br/>server先sleep 100ms, 再将请求字符串返回
+- rpc-echo服务<br/>server将请求转发至server2, server2将请求字符串直接返回
+- 延时rpc-echo服务<br/>server将请求转发至server2， server2先sleep 100ms, 再将请求字符串返回
+
+备注：请求字符串小于100字节
+
+## TCP请求连接模式
+
+- 短连接<br/>每个请求都需要建立TCP连接
+- 长连接<br/>建立TCP连接后，保持不断开，连续发送请求
+
+## 程序A测试结果(QPS及延时分布)
+
+| | QPS | CPU | <5ms | 5 ~ 10ms | 10 ~ 30ms| 30 ~ 50ms | >50ms |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| 长连接 | 85,000/s | 98% | 99.25% | 0.66% | 0.09% | 0 | 0 |
+| 短连接 | 30,000/s | 70% | 94.50% | 5.30% | 0.20% | 0 | 0 |
+
+备注：短连接并没有压满CPU，因为proxy为单进程，成为瓶颈。
+
+## 程序B测试结果QPS
+
+| | QPS | CPU | <120ms | 120 ~ 150ms | 150 ~ 200ms | > 200ms |
+| --- | --- | --- | --- | --- | --- | --- |
+| 长连接 | 55,000/s | 89% | 94.71% | 4.83% | 0.25% | 0.21% |
+| 短连接 | 25,000/s | 70% | 93.12% | 3.11% | 1.72% | 2.05% |
+
+备注：CPU并没有压满，继续往上压，时延明显变大。
+
+## 程序C测试结果QPS
+
+| | QPS | CPU | <5ms | 5 ~ 10ms | 10 ~ 30ms| 30 ~ 50ms | >50ms |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| 长连接 | 45,000/s | 88% | 26.67% | 72.06% | 1.27% | 0.002% | 0.015% | 
+| 短连接 | 30,000/s | 70% | 52.33% | 46.81% | 0.84% | 0.02% | 0 |
+
+备注：都没有压满CPU，压满CPU后时延明显变大。
+
+## 程序D测试结果QPS
+
+| | QPS | CPU | <120ms | 120 ~ 150ms | 150 ~ 200ms | > 200ms |
+| --- | --- | --- | --- | --- | --- | --- |
+| 长连接 | 45,000/s | 92% | 48.77% | 47.54% | 3.30% | 0.39% |
+| 短连接 | 25,000/s | 78% | 95.40% | 0.85% | 0 | 3.76% |
+
+备注：短连接proxy成为瓶颈。

document/msec/php_dev_manual.md

@@ -418,41 +418,3 @@ Content-Length: 63
 
 配置同c++，详见cpp_dev_manual.md中的[SRPC配置说明](cpp_dev_manual.md#srpc配置说明)一节。
 
-
-## 2.8. 性能测试
-
-#### 测试环境
-```
-CPU: 4 x Intel(R) Xeon(R) CPU X3320 @ 2.50GHz
-内存: 8 GB
-网卡: 千兆网卡
-业务数据大小：13bytes业务数据
-```
-
-#### 测试用例
-
-使用三台机器做测试，A固定做客户端，B和C做SRPC服务器。A和B属于同一机房，时延0.8毫秒，C为异地机房，A和B和它的时延模拟为100毫秒左右。
-- 用例一 <br/>
-A <--> B : A直接和B通信，裸测Echo的性能。
-- 用例二 <br/>
-A <--> B <--> C : A和B通信，B做中转到C，C做Echo，关注B的性能数据。模拟真实业务场景的性能。
-- 用例三 <br/>
-A <--> B <--> A : A和B通信，B做中转到A，A运行客户端和Echo服务器。和用例二的区别在于，中转服务器不会在IO中有太长的等待时间。
-
-#### 性能数据
-
-| 用例类型 | Client IO线程数 | worker进程数 | qps | 时延(ms) | CPU占用 |
-| --- | --- | --- | --- | --- | --- |
-| 用例一 | 10 | 4 | 6K | 1 | 65% |
-| 用例一 | 50 | 4 | 8.5K | 6 | 98% |
-| 用例二 | 100 | 100 | 1K | 102 | 15% |
-| 用例二 | 200 | 200 | 1.9K | 103 | 30% |
-| 用例二 | 300 | 300 | 2.9K | 104 | 50% |
-| 用例二 | 400 | 400 | 1K | 300+ | 95% |
-| 用例三 | 20 | 10 | 5K | 3 | 85% |
-| 用例三 | 20 | 20 | 5.5K | 3 | 90% |
-
-
-#### 测试说明
-
-用例二由于IO时延很大，所以开了多个进程工作，进程数越多，SRPC框架的惊群越严重，并且极不稳定。我们看到在400个进程的时候，性能并没有得到线性增长。所以，具体业务的进程数需要业务开发者自己确认一个合适的值。

document/msec/php_performance.md

@@ -0,0 +1,55 @@
+## 运行环境
+
+```
+CPU: Intel(R) Xeon(R) CPU X3320  @ 2.50GHz  4核
+内存：8GB
+网卡：千兆网卡
+Client与Server之间PING值：0.854ms
+
+```
+
+## 测试程序
+
+- echo服务<br/>server将请求字符串直接返回
+- 延时echo服务<br/>server先sleep 100ms, 再将请求字符串返回
+- rpc-echo服务<br/>server将请求转发至server2, server2将请求字符串直接返回
+- 延时rpc-echo服务<br/>server将请求转发至server2， server2先sleep 100ms, 再将请求字符串返回
+
+备注：请求字符串小于100字节
+
+## TCP请求连接模式
+
+- 短连接<br/>每个请求都需要建立TCP连接
+- 长连接<br/>建立TCP连接后，保持不断开，连续发送请求
+
+## 程序A测试结果(QPS及延时分布)
+
+| | QPS | CPU | <5ms | 5 ~ 10ms | 10 ~ 30ms| 30 ~ 50ms | >50ms |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| 长连接 | 8,500/s | 96% | 88.56% | 10.02% | 0.01% | 0.01% | 0 |
+| 短连接 | 6,300/s | 91% | 93.71% | 5.60% | 0.58% | 0 | 0.11% |
+
+
+## 程序B测试结果QPS
+
+| QPS | CPU | <120ms | 120 ~ 150ms | 150 ~ 200ms | > 200ms |
+| --- | --- | --- | --- | --- | --- |
+| 2,900/s | 45% | 100% | 0 | 0 | 0 |
+
+备注：该用例没有区分长连接和短连接，后端sleep 100ms，主要是依靠增加进程数来提高处理能力，由于框架本身存在的惊群效应等原因，这里配置为300个进程，如果继续增加，会导致时延加重。
+
+## 程序C测试结果QPS
+
+| | QPS | CPU | <5ms | 5 ~ 10ms | 10 ~ 30ms| 30 ~ 50ms | >50ms |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| 长连接 | 5,900/s | 92% | 99.21% | 0.61% | 0.06% | 0 | 0.11% |
+| 短连接 | 4,100/s | 78% | 93.90% | 5.83% | 0.16% | 0 | 0.11% |
+
+
+## 程序D测试结果QPS
+
+| QPS | CPU | <120ms | 120 ~ 150ms | 150 ~ 200ms | > 200ms |
+| --- | --- | --- | --- | --- | --- |
+| 2,900/s | 52% | 100% | 0 | 0 | 0 |
+
+备注：该用例没有区分长连接和短连接，后端sleep 100ms，主要是依靠增加进程数来提高处理能力，由于框架本身存在的惊群效应等原因，这里配置为300个进程，如果继续增加，会导致时延加重。

document/msec/python_performance.md

@@ -0,0 +1,55 @@
+## 运行环境
+
+```
+CPU: Intel(R) Xeon(R) CPU X3320  @ 2.50GHz  4核
+内存：8GB
+网卡：千兆网卡
+Client与Server之间PING值：0.854ms
+
+```
+
+## 测试程序
+
+- echo服务<br/>server将请求字符串直接返回
+- 延时echo服务<br/>server先sleep 100ms, 再将请求字符串返回
+- rpc-echo服务<br/>server将请求转发至server2, server2将请求字符串直接返回
+- 延时rpc-echo服务<br/>server将请求转发至server2， server2先sleep 100ms, 再将请求字符串返回
+
+备注：请求字符串小于100字节
+
+## TCP请求连接模式
+
+- 短连接<br/>每个请求都需要建立TCP连接
+- 长连接<br/>建立TCP连接后，保持不断开，连续发送请求
+
+## 程序A测试结果(QPS及延时分布)
+
+| | QPS | CPU | <5ms | 5 ~ 10ms | 10 ~ 30ms| 30 ~ 50ms | >50ms |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| 长连接 | 32,000/s | 89% | 99.92% | 0.07% | 0.01% | 0 | 0 |
+| 短连接 | 25,000/s | 96% | 98.68% | 1.19% | 0.14% | 0 | 0 |
+
+
+## 程序B测试结果QPS
+
+| QPS | CPU | <120ms | 120 ~ 150ms | 150 ~ 200ms | > 200ms |
+| --- | --- | --- | --- | --- | --- |
+| 2,900/s | 23% | 100% | 0 | 0 | 0 |
+
+备注：该用例没有区分长连接和短连接，后端sleep 100ms，主要是依靠增加进程数来提高处理能力，由于框架本身存在的惊群效应等原因，这里配置为300个进程，如果继续增加，会导致时延加重。
+
+## 程序C测试结果QPS
+
+| | QPS | CPU | <5ms | 5 ~ 10ms | 10 ~ 30ms| 30 ~ 50ms | >50ms |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| 长连接 | 12,000/s | 71% | 99.30% | 0.53% | 0.17% | 0 | 0 |
+| 短连接 | 10,000/s | 72% | 98.06% | 1.94% | 0 | 0 | 0 |
+
+
+## 程序D测试结果QPS
+
+| QPS | CPU | <120ms | 120 ~ 150ms | 150 ~ 200ms | > 200ms |
+| --- | --- | --- | --- | --- | --- |
+| 2,900/s | 36% | 100% | 0 | 0 | 0 |
+
+备注：该用例没有区分长连接和短连接，后端sleep 100ms，主要是依靠增加进程数来提高处理能力，由于框架本身存在的惊群效应等原因，这里配置为300个进程，如果继续增加，会导致时延加重。