测试机: amd 两核心 ,客户端与服务端都在本机上跑。

网络层:A类epoll线程处理accept的被动连接;
B类epoll线程处理connect的主动连接;
C类epoll线程把A或B类epoll线程得到的连接分配到某个线程,专门处理send和recv操作;
D类线程池处理C类抛出来的数据,处理完之后,再投递到C类线程做send操作。

用ab测试短连接
ab -n 1000 -c 150 http://127.0.0.1:8090/
测试20次之后,得到一个峰值tps=6000



用字节的写的基于数据echo测试的压力测试程序测试长连接:
client发出64字节数据,echosvrd返回64字节,client又发出64字节。

每次传输网络传输数据在64字节以下的情况下: 
./stree_client 127.0.0.1 8090 100    得到tps=13851
./stree_client 127.0.0.1 8090 1000   得到tps=16641
./stree_client 127.0.0.1 8090 10000  得到tps=16600 service cpu跑到90%,始终在90%以下;stree_client的cpu跑到32%左右;
./stree_client 127.0.0.1 8090 20000  stree_client的cpu跑到100%告终
./stree_client 127.0.0.1 8090 15000  stree_client的cpu跑到100%告终

把日志的输出级别调到1,此时基本无日志输出:
./stree_client 127.0.0.1 8090 10000  得到tps=29436 service cpu跑到70%;stree_client的cpu跑到48%左右;
./stree_client 127.0.0.1 8090 15000  stree_client的cpu跑到100%告终

再把网络传输的字节调整为128字节左右:
./stree_client 127.0.0.1 8090 10000  得到tps=29179 service cpu跑到68%;stree_client的cpu跑到45%左右;

结论:
在本机测试,就忽略了网络io时延,得到网络引擎cpu跑到100%时的tps是 不超过30000,或者不偏离30000很远,
此时并发连接数在10000