ASIO,无锁,高并发,高可靠, 统一,网络架构,抗DOS,低端4核心服务器CPU 每秒87万QPS ECHO

wlmqgzm

回复 117# windoze

你说的对, 这个改进当然还是有必要的, 提高了大并发下新建连接的性能, 并且实际应用中, 性能肯定有所改善.  测试不能全面反映情况.
已经将代码中的内存管理, 换用tcmalloc了, 能简单压出一点性能的地方, 都要用上.  

g++  -o bin/Release/echo_server obj/Release/main.o  -s  -lboost_thread -lboost_system -lboost_timer -ltcmalloc_minimal

windoze

回复 118# wlmqgzm

对于框架，我还是觉得自制一个memory pool会比较好，因为框架里的内存分配使用情况基本是已知的，用memory pool可以（几乎）完全消除掉所有的内存分配和释放。

benjiamsh

....900的并发  其实你测试的是大块数据的传输， 这根本没什么压力。 把连接数提到100万以后，再来做测试。 你能做到50wqps 都很高了！

windoze

回复 120# benjiamsh

就算只有100个并发，50wqps都已经很高了……

wlmqgzm

装新版本apche测试了一下, 14万QPS, 比以前快太多了, 使用了3个进程, 类似Nginx一样, 640%CPU占有率.


Tasks: 257 total,   2 running, 255 sleeping,   0 stopped,   0 zombie
%Cpu(s): 44.1 us, 40.4 sy,  0.0 ni,  7.2 id,  0.0 wa,  0.0 hi,  8.3 si,  0.0 st
KiB Mem:  32865404 total, 32151444 used,   713960 free,    38364 buffers
KiB Swap:        0 total,        0 used,        0 free.  2360056 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND   
  836 www-data  20   0  429160   5676   3200 S 215.1  0.0   5:28.67 apache2   
1851 www-data  20   0  429168   5660   3196 S 211.8  0.0   2:20.23 apache2   
1944 www-data  20   0  363552   6452   3196 S 211.4  0.0   2:17.65 apache2   
3597 guo       20   0  342740 198752   3792 R  96.4  0.6   0:41.11 ab         
1631 root      20   0  298504  71440  22312 S   1.3  0.2   2:11.55 Xorg      
1823 guo       20   0 1512404 121548  57756 S   1.0  0.4   0:51.22 compiz   


guo@guo-desktop:~$ ab -n 10000000 -c 100 -k h ttp://127.0.0.1:80/jjjjjjjjjjjjj
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd,
Licensed to The Apache Software Foundation,

Benchmarking 127.0.0.1 (be patient)
Completed 1000000 requests
Completed 2000000 requests
Completed 3000000 requests
Completed 4000000 requests
Completed 5000000 requests
Completed 6000000 requests
Completed 7000000 requests
Completed 8000000 requests
Completed 9000000 requests
Completed 10000000 requests
Finished 10000000 requests


Server Software:        Apache/2.4.10
Server Hostname:        127.0.0.1
Server Port:            80

Document Path:          /jjjjjjjjjjjjj
Document Length:        286 bytes

Concurrency Level:      100
Time taken for tests:   70.516 seconds
Complete requests:      10000000
Failed requests:        650694
   (Connect: 0, Receive: 0, Length: 650694, Exceptions: 0)
Non-2xx responses:      9349306
Keep-Alive requests:    9340724
Total transferred:      4693620099 bytes
HTML transferred:       2673901516 bytes
Requests per second:    141811.99 [#/sec] (mean)
Time per request:       0.705 [ms] (mean)
Time per request:       0.007 [ms] (mean, across all concurrent requests)
Transfer rate:          65001.13 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       4
Processing:     0    1   1.1      1     184
Waiting:        0    1   1.1      0     184
Total:          0    1   1.1      1     184

Percentage of the requests served within a certain time (ms)
  50%      1
  66%      1
  75%      1
  80%      1
  90%      1
  95%      2
  98%      3
  99%      4
100%    184 (longest request)
guo@guo-desktop:~$

wlmqgzm

准备抽时间研究一下 apache的代码,  看能否把整个底层网络架构移植过去,

第一次做代码移植, 估计会遇到很多困难, 希望能够解决, 自己读代码的能力很有限, 唉.....................

如果移植成功, 就测试一下, 对比现有的apache网络架构, 看能否提高, 或者提高多少, 最近一段时间就准备忙这个事情了.   


目前的apache底层网络架构也已经采用事件驱动模式了, 所以速度快了很多.  
/var/lib/apache2/module/enabled_by_maint/mpm_event

benjiamsh

回复 121# windoze
客观的说 50wqps 看如何认定？ 一个echo的信息有多大， 如果一条信息长度为1k 字节 和 1条信息的长度为1M 同一个服务器能保证一样的QPS吗？
其次 echo 服务器本身 内部没有业务逻辑， 所以就是一个简单的network IO 的操作， 大块的数据传输可以非常高的提高速度。 如果是一个1000M 网卡
那么普通一个循环 可以将整个网卡流量打满 而达到系统的瓶颈。

那么每秒的100M 数据吞吐，如果以一条消息为100字节， 简单的echo 服务器，可以做到全速的吞吐 那么QPS 就是1M 也就是100w 无须任何架构。 即使最差的服务器也是绰绰有余。

所以使用大量的连接 和 慢速的吞吐数度 才是真正贴近真实的系统。

拿一个ab 来测的，我只说一句 这个QPS的瓶颈 你需要确认是client 测试方的还是 服务器测试的 。   

wlmqgzm

回复 124# benjiamsh

benjiamsh 发表于 2015-11-03 17:50
那么每秒的100M 数据吞吐，如果以一条消息为100字节， 简单的echo 服务器，可以做到全速的吞吐 那么QPS 就是1M 也就是100w 无须任何架构。 即使最差的服务器也是绰绰有余。.

ECHO SERVER就是来测试小数据包的, 看来你没有做过网络架构的边开发边测试, 一般都用这个简单服务器来测试底层网络的小字节包的处理瓶颈, 测试的不是字节数量, 测试的是数据包的量, 每个数据包可以是1-几百字节都无所谓.
测试端每次只发1个数据包, 服务端回一个一模一样的包, 跟PING一样,
100万QPS ECHO就是说每秒钟要PING 100万次, 这个是: "发出1个独立数据包, 等待响应, 收1个独立数据包", 这样重复的动作有100万次.
收到回包后, 客户端才会发下一个包, 注意: 不是连续发包, 是一定要等服务器响应回复的, 所以ab测试指标中才有最大响应时间, 平均响应时间等概念,
因此, 测试软件ab发出的IP数据包的数量非常巨大, 每个包非常小, 不是测试网络带宽的, 是测试包处理能力的.

同样用ab测试网络架构, 同样ECHO SERVER, 有的网络架构只能达到几千, 有的达到几十万, 还是有很大区别的.  在程序开发阶段, 找一个简单易用的测试工具, 对于开发代码有很大的指导作用.
即使是测试 最流行的WWW服务器Apache本身( ab也是apache开发的测试http服务器的程序),  回复数据就是几十个字节, 采用epoll底层的新版本的测试指标比过去老版本提高十倍以上, 测试指标也是能够说明技术架构, 对于性能的提高是非常明显的.

另外, 底层网络架构做好, 真的很不容易, 大公司对网络架构的重视, 超出你的想象, 都是有专业团队的,  
你自己找个服务器代码, 测试一下就知道了, 没有你想象的那么简单, 性能做好了不容易, 做安全做可靠了也非常不容易, 需要大量的基础工作.
目前开源的超过10万QPS ECHO的网络层开源代码都是牛人的大作.
很多游戏公司, 都有自己独立开发的网络框架, 为了性能, 也是走到网络框架的前头, 不是随便写点代码就可以用的.

底层框架采用ASIO以后, 在代码中理论上可以承受100万以上连接, 还可以稳定运行, 继续保持一定的处理能力,  但是彻底测试这个东西, 本身就是一项比较大的工程,
真正网络框架定型后, 代码彻底完成后, 如果要找出极限指标来,  是要找很多机器测试的, 每个IP只能开6万个并发(受socket端口号理论数量限制, 还要改linux默认配置, 才能实现6万), 要测试120万个并发,
最少要多找几台机器做客户端, 要做专门的测试客户端软件, 找一群机器狂轰主服务器, 显然比较麻烦.

目前, 代码还有可改进的地方, 以后再说吧.  在边学习, 边写代码中.......

wlmqgzm

回复 124# benjiamsh

我们这些码农, 做网络层代码, 很多都有用ab测试的习惯, 主要是简单,直观,免费,迅速.

为了对比, 我先在本论坛找一个2009年的高性能高并发的网络层框架, 1万QPS ECHO, 当时就很了不起了, 也是ab测试的,
<<发布一个我写的 高性能，高并发的python网络服务器开发框架>>   http://bbs.chinaunix.net/thread-1595500-1-1.html

这个是最新版本的swoole,  一个开源的高性能, 高并发网络架构, 底层调用Epoll,  2014年12月的自我评价内容: 也是测试ab进行测试.
"通过使用apache bench工具进行压力测试，在Inter Core-I5 4核 + 8G内存的普通PC机器上，swoole_http_server可以达到近11万QPS。远远超过php-fpm，golang自带http服务器，node.js自带http服务器。性能几乎接近与Nginx的静态文件处理。"

benjiamsh

呵呵，很明显，我有足够的能力 以及足够的经验，所以才能指出你测试的错误。
至于你说ab发的是小包 我就只能呵呵了。

至于百万连接 你应该先做做看。github搜索c1000k 去看我的代码即可。