[基于Epoll内置Leader-Follower服务端实现, 已可达50万echo qps（全新支持Lua啦）]

linux_c_py_php

回复 70# yulihua49


sar -n DEV 1 1000 看网卡流量, 跨机器测试我也没试, 这个QPS肯定会达到网卡的中断瓶颈, 据传18万qps的服务就会把单核软中断打满了.

linux_c_py_php

我这里测了不同机器间请求, 同机房8万就上不去了, sys已经45了, idle剩40.

yulihua49

linux_c_py_php 发表于 2013-02-19 12:24
回复 70# yulihua49

qps=115606,估计是网络瓶颈了。

13时08分04秒     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
13时08分07秒        lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
13时08分07秒      eth0 157721.96 157681.96  10166.03  10164.65      0.00      0.00      0.00
13时08分07秒    virbr0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
13时08分07秒 virbr0-nic      0.00      0.00      0.00      0.00      0.00      0.00      0.00

rxkb，txkb，达到10M（100M网，极限是12M），基本网络饱和了。
这里qps=157721.
如果想提高qps，需要1G LAN。

平均时间:       IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
平均时间:          lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
平均时间:        eth0 154068.00 154015.37   9931.16   9928.17      0.00      0.00      0.00
平均时间:      virbr0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
平均时间:   virbr0-nic      0.00      0.00      0.00      0.00      0.00      0.00      0.00

cookis

为什么要用，EPOLLONESHOT？  一个线程一个epoll_wait， accept到新句柄后，直接交给各线程epoll_wait 不行吗？ 你那样做线程切换太频繁了

yulihua49

cookis 发表于 2013-02-19 13:03
为什么要用，EPOLLONESHOT？  一个线程一个epoll_wait， accept到新句柄后，直接交给各线程epoll_wait 不行 ...

源码楼主已经给了，你拿去试一试，看看去掉ONESHOT行不行。
楼主帖子改名了啊，害得我找不到。


改用ET模式：
平均时间:       IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
平均时间:          lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
平均时间:        eth0 153094.77 153045.05   9868.27   9865.65      0.00      0.00      0.00
平均时间:      virbr0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
平均时间:   virbr0-nic      0.00      0.00      0.00      0.00      0.00      0.00      0.00



Cpu0  :  3.5%us, 45.0%sy,  0.0%ni, 31.9%id,  0.0%wa,  0.0%hi, 19.6%si,  0.0%st
Cpu1  :  3.0%us, 48.1%sy,  0.0%ni, 29.2%id,  0.0%wa,  0.0%hi, 19.7%si,  0.0%st
Mem:   8059424k total,   544412k used,  7515012k free,    93168k buffers
Swap:  8191992k total,        0k used,  8191992k free,    81008k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                          
17298 sdbc      20   0 96372 9752  396 R 15.9  0.1   0:31.93 server                                            
17299 sdbc      20   0 96372 9752  396 R 15.9  0.1   0:31.81 server                                            
17303 sdbc      20   0 96372 9752  396 R 15.9  0.1   0:31.58 server                                            
17300 sdbc      20   0 96372 9752  396 R 15.6  0.1   0:31.78 server                                            
17301 sdbc      20   0 96372 9752  396 R 15.6  0.1   0:31.59 server                                            
17305 sdbc      20   0 96372 9752  396 R 15.6  0.1   0:31.79 server                                            
17302 sdbc      20   0 96372 9752  396 R 15.3  0.1   0:31.63 server                                            
17304 sdbc      20   0 96372 9752  396 R 15.3  0.1   0:31.73 server                                            
1661 root      20   0     0    0    0 R  0.3  0.0   0:09.14 kondemand/1


qps=115810. 有限提高。

linux_c_py_php

cookis 发表于 2013-02-19 13:03
为什么要用，EPOLLONESHOT？  一个线程一个epoll_wait， accept到新句柄后，直接交给各线程epoll_wait 不行 ...

前提是leader-follower可以发挥多核优势, 传统的epoll event loop处理能力是CPU受限的, 很容易就到瓶颈了,  因为FD是排着队一个一个串行处理的, 并且难以满足慢处理业务逻辑, 一个FD卡了所有FD都得等着, 而leader-follower不仅拥有传统epoll的事件检测能力, 并且通过多线程并发I/O与计算, 上下文切换并不高, 你自己vmstat实测一下就知道了.

采用了leader-follower架构, 可以跑满所有的核心, 并且允许慢处理业务逻辑而不会影响其他FD在其他线程里继续并发.

linux_c_py_php

yulihua49 发表于 2013-02-19 13:26
源码楼主已经给了，你拿去试一试，看看去掉ONESHOT行不行。
楼主帖子改名了啊，害得我找不到。

貌似ET表现不如LT, 是不是

yulihua49

linux_c_py_php 发表于 2013-02-19 15:04
貌似ET表现不如LT, 是不是

从sar -n 的数据来看，稍差。
从客户端完成全部任务的历时来看，稍高。
总之，差不多。所以我原来的那个LT框架也不打算改了。

linux_c_py_php

yulihua49 发表于 2013-02-19 15:13
从sar -n 的数据来看，稍差。
从客户端完成全部任务的历时来看，稍高。
总之，差不多。所以我原来的那个 ...

嗯, 我昨天测的时候就发现ET从服务端来看变差了.

不管怎么说, 单一epoll fd有瓶颈这个关键点找到了, 瓶颈化解了, 以后写这一类server基本可以无忧了.

yulihua49

linux_c_py_php 发表于 2013-02-19 15:15
嗯, 我昨天测的时候就发现ET从服务端来看变差了.

不管怎么说, 单一epoll fd有瓶颈这个关键点找到了, ...

这次是因为网络饱和了。如果不饱和怎么样还要看看。