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

wlmqgzm

继续优化, 简单修改测试软件的并发线程数量为100, 测试达到了每秒23.7万QPS 的性能,  还算不错.
大约每4微秒处理一个收发包, 效率确实很高.
主要还是双核 G3258 的性能太差.  


guo@guo-desktop:~$ ab -n 10000000 -c 100 -k   h t t p ://127.0.0.1:1971/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:        
Server Hostname:        127.0.0.1
Server Port:            1971

Document Path:          /jjjjjjjjjjjjj
Document Length:        0 bytes

Concurrency Level:      100
Time taken for tests:   42.201 seconds
Complete requests:      10000000
Failed requests:        0
Non-2xx responses:      10000000
Keep-Alive requests:    10000000
Total transferred:      1190000000 bytes
HTML transferred:       0 bytes
Requests per second:    236962.46 [#/sec] (mean)
Time per request:       0.422 [ms] (mean)
Time per request:       0.004 [ms] (mean, across all concurrent requests)
Transfer rate:          27537.63 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       6
Processing:     0    0   0.2      0      18
Waiting:        0    0   0.2      0      18
Total:          0    0   0.2      0      18

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

windoze

回复 11# wlmqgzm

嗯，这个数字以你的机器配置而言差不多到了ASIO的尽头了。

话说回来其实也不用特别纠结锁这事，在Linux下用epoll+多线程，想要没锁几乎是不可能的事，除非就像我之前说的那样，每个线程一个epollfd，不过这样又会有load balance的问题。
一般在大型应用中常见的做法是划分几个io_service/epollfd，每个io_service对应一组线程，这样既不会让负载特别不平衡，也能充分利用多个CPU core，尤其是服务器上有几十上百个core的时候，放在一个thread pool里调度简直是丧心病狂。

对于高负载应用，想要进一步提高性能还有几个思路，一个是interrupt coalescing以减少内核中断的次数，不过这个需要硬件核驱动的支持；一个是CPU/NIC/thread绑定，这样可以减少cache miss，另一个就是user-mode networking stack（当然这就是一个大坑），或者就像OSv那样干脆把你的应用放到核心态运行，这样Ring 0/3切来切去的开销就没有了。

至于TOE之类死贵的解决方案就不提了，反正不是壕公司不会用这玩意儿，再说这玩意儿其实也不太好用。

cokeboL

一万行已经很多了。。

我用c，单worker_thread，不同worker_thread合作用消息(跟锁或者单进程内多线程相比的好处是可以跨硬件），核心框架部分估计一千行左右？反正不多

另外你再用golang试试，so easy

wlmqgzm

回复 13# cokeboL

主要是测试代码和注释多,  还有很多Google flatbuffer, Google prot buff, 管理层, 安全可靠层, 等等其他的东西,  如果只做了一个标准简单 echo server版本,  大约也只需要1000行.     


   

wlmqgzm

继续优化, 发现std::shared_str代替boost::shared_str,  std::bind替代boost::bind 等等, 优先使用std的策略,  性能又提高了5%.   现在是25.2万QPS ECHO

guo@guo-desktop:~$ ab -n 10000000 -c 100 -k h t t p : / / 127.0.0.1:1971/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:        
Server Hostname:        127.0.0.1
Server Port:            1971

Document Path:          /jjjjjjjjjjjjj
Document Length:        0 bytes

Concurrency Level:      100
Time taken for tests:   39.622 seconds
Complete requests:      10000000
Failed requests:        0
Non-2xx responses:      10000000
Keep-Alive requests:    10000000
Total transferred:      1190000000 bytes
HTML transferred:       0 bytes
Requests per second:    252387.91 [#/sec] (mean)
Time per request:       0.396 [ms] (mean)
Time per request:       0.004 [ms] (mean, across all concurrent requests)
Transfer rate:          29330.24 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       5
Processing:     0    0   0.2      0      79
Waiting:        0    0   0.2      0      79
Total:          0    0   0.2      0      79

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      0
  95%      1
  98%      1
  99%      1
100%     79 (longest request)

wlmqgzm

继续改进, 将大部分shared_ptr指针用 引用和wek_ptr代替, 以及合并指针, 连接收发处理使用内存预分配,  大幅度提高了性能. 大约20%性能的提高.  目前双核奔腾G3258下,  ECHO服务器的性能已经超过了31万QPS ECHO, 应该算很快了.  

guo@guo-desktop:~$ ab -n 10000000 -c 100 -k h t t p : / / 127.0.0.1:1971/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:        
Server Hostname:        127.0.0.1
Server Port:            1971

Document Path:          /jjjjjjjjjjjjj
Document Length:        0 bytes

Concurrency Level:      100
Time taken for tests:   32.093 seconds
Complete requests:      10000000
Failed requests:        0
Non-2xx responses:      10000000
Keep-Alive requests:    10000000
Total transferred:      1190000000 bytes
HTML transferred:       0 bytes
Requests per second:    311597.12 [#/sec] (mean)
Time per request:       0.321 [ms] (mean)
Time per request:       0.003 [ms] (mean, across all concurrent requests)
Transfer rate:          36210.99 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       5
Processing:     0    0   0.2      0      36
Waiting:        0    0   0.2      0      36
Total:          0    0   0.2      0      38

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

wlmqgzm

修改自己代码中内存垃圾回收机制, 为500毫秒回收一次,  将工作线程数设置为CPU数2倍,  又提高8%性能.  33万QPS.

Server Software:        
Server Hostname:        127.0.0.1
Server Port:            1971

Document Path:          /jjjjjjjjjjjjj
Document Length:        0 bytes

Concurrency Level:      20
Time taken for tests:   0.003 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Keep-Alive requests:    100
Total transferred:      11900 bytes
HTML transferred:       0 bytes
Requests per second:    33014.20 [#/sec] (mean)
Time per request:       0.606 [ms] (mean)
Time per request:       0.030 [ms] (mean, across all concurrent requests)
Transfer rate:          3836.61 [Kbytes/sec] received

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

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

wlmqgzm

测试达到了ECHO服务器 每秒33万QPS ECHO 的性能,  还算不错.
大约每3微秒处理一个ECHO,  效率确实很高,
具体每个步骤, 都是按照高可靠服务器的网络设计规范要求来实现,  每个操作又分为多个子步骤, 例如: 即使是简单的主动拆除连接, 就不是简单的socket close了之,  就包括: shutdown receive, wait, shutdown send, wait, hard close或者soft close等,  可以保证满足在网络连接正常的情况下, 正常退出服务器, 按照高可靠设计规范来设计的标准网络客户端不丢失一个数据包. 不是民用级别的

在正常网络情况下,  无论是哪一端主动拆线, 在底层TCP/IP协议的协调下,  在 服务器端不会出现一个典型的常见的30秒到4分钟(取决于linux版本)的 time_wait socket, 这个是aparche服务器未开长连接的经典情况,  
在高可靠网络设计中,  time_wait socket一律出现在标准客户端.
在网络正常情况下, 大部分民用级别的软件, 做不到退出不丢失一个数据包, 这个也是我要开发这个基础包的原因之一.

总之, 关键设计满足 高可靠服务器 的 流程 设计 规范, 不是民用级别的,  

网络服务器这一层的开发定型后, 后续是更高一层的数据接口层, 夹在Google flatbuffer, Google protbuff等 和TC/IP层之间,  实现了数据分包和纠错处理的层.
这一层的数据包规范的开发, Google其实没有公开全部信息, 还有部分高可靠性设计在里面,  不是民用级别的,
高可靠网络设计, 即使TCP/IP层出现错误, 也能满足不丢失一个数据包, 就是在网络服务器层上再包装一个安全可靠层级, 最后的代码流, 使用上与TCP/IP一样, 但是, 可靠性达到了永远不会错一个码的. 纠错码有2组以上, 位数很长.

TCP/IP最大的问题是纠错检测码只有16bit, 远程传输如果出错, 或者路由器端少发一个字节, 有6.5万分之一的概率, 错误无法检测到,  民用级别的,

wlmqgzm

无mutex,  真正无锁的高并发服务器架构,  呵呵.  
更重要的还在后面, 就是高可靠网络内核设计.

测试达到了ECHO服务器 每秒33万QPS新建连接 的性能,  还算不错.
主要还是intel 双核 奔腾G3258 的性能太差,  毕竟是最低端的CPU,
测试操作系统版本是国产桌面版 Ubuntu Kylin 桌面,  换服务器版本性能还能提高.

大约每3微秒处理一个连接,  效率确实很高, 包括连接建立, 申请内存, 注册连接管理信息(超时等), 收数据, 发数据, 拆除连接, 删除管理信息. 等步骤.  
具体每个步骤, 都是按照高可靠服务器的网络设计规范要求来实现,  每个操作又分为多个子步骤, 例如: 即使是简单的主动拆除连接, 就不是简单的socket close了之,  就包括: shutdown receive, wait, shutdown send, wait, hard close或者soft close等,  可以保证满足在网络连接正常的情况下, 正常退出服务器, 按照高可靠设计规范来设计的标准网络客户端不丢失一个数据包. 不是民用级别的

在正常网络情况下,  无论是哪一端主动拆线, 在底层TCP/IP协议的协调下,  在 服务器端不会出现典型的常见的30秒到4分钟(取决于linux版本)的 time_wait socket, 这个是aparche服务器未开长连接的经典情况,  
在高可靠网络设计中,  time_wait socket一律出现在标准客户端.
在网络正常情况下, 大部分民用级别的软件, 做不到重启进程过程, 或者退出过程中, 不丢失一个数据包, 这个也是我要开发这个基础包的原因之一.
总之, 关键设计满足 高可靠服务器 的 流程 设计 规范, 不是民用级别的,  

后续展望:
网络服务器这一层的开发定型后, 后续是更高一层的数据接口层, 夹在应用层 和TCP/IP层之间,  类似 Google flatbuffer, Google protbuff等, 实现了数据切包.   但是我的多一个设计,  就是可靠性设计, 也是纠错处理的层
这一层的数据包规范的开发, 以及安全可靠层, Google其实没有公开全部信息, 还有部分高可靠性设计在里面,  不是民用级别的,  
高可靠网络设计, 即使TCP/IP层出现错误, 也能满足不丢失一个数据包, 就是在网络服务器层上再包装一个安全可靠层级, 最后的代码流, 使用上与TCP/IP一样, 但是, 可靠性达到了永远不会错一个码的. 纠错码有2组以上, 位数很长.
TCP/IP最大的问题是纠错检测码只有16bit, 远程传输如果出错, 或者路由器端少发一个字节, 有6.5万分之一的概率, 错误无法检测到,  民用级别的,

总之, 后续的部分代码也已经开发出来,  即使是增加了大量纠错流程后, 我希望性能还是能够过Google protbuff协议, 现在还在做代码中,  呵呵呵呵

wlmqgzm

回复 12# windoze

还在继续优化代码,  感觉性能上还可以继续提高,  无锁的世界多么美好.   

现在已经达到了33万,  还有提高的空间.  包括内存管理方面, 内存垃圾回收机制方面等等
看一个月后, 最终的性能会怎样.