测试机： 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