[基于Epoll内置Leader-Follower服务端实现, 已可达50万echo qps（全新支持Lua啦）]
本帖最后由 linux_c_py_php 于 2013-02-21 17:38 编辑程序在论坛众亲友的给力指导下, 在公司内核部门的指导之下, 长连接性能最终达到了50万qps, 短连接性能最终达到了7万qps, 测试机器CPU为12核心, 64MB内存, 测试环境为单机lo网口.
程序基于epoll的EPOLLONESHOT选项, 充分利用了epoll的线程安全特性, 通过独立的监听线程最大化连接建立速率, 通过线程池配合epoll简易的实现了Leader-Follower的程序结构, 对于各类业务逻辑能够普遍适用.
程序优化过程中, 主要是2个瓶颈点的化解:
1, epoll线程安全, 所以内部的锁会造成多线程共享epoll fd的瓶颈, 通过创建多组epoll fd, 减小锁的竞争可以化解瓶颈, 充分利用硬件性能.
2, 短连接建立能力差, 未经过优化网络参数, 只能达到3万/秒的建立能力, 经过参数优化, 可以达到8万/秒的建立能力, 具体参数参考代码里的Readme.
代码如下，最初的255行小代码, 有明显的瓶颈：(15万QPS)
解决上述两个问题后的代码, 能够支撑50万qps:
这是引入了lua的代码, 不支持yield, 因为考虑到需要把代码改成状态机的太费劲, 并且程序本身就是leader-folllower的, 所以提供一些异步connect等实用接口的必要性不大:
测试lua版本性能, 发现luaL_loadstring频繁调用性能损耗严重, 所以做成了只加载一次, 然后保持一份引用在注册表里, 以便重复使用, 现在程序瓶颈已经转移到了lua_pcall, 目测已经无法优化了.（注意测试前修改logic.lua, 改为纯echo服务, 否则会导致test压力工具工作不正常）
本帖最后由 linux_c_py_php 于 2013-02-18 00:13 编辑
留楼12345. 应该不是这个问题吧，所有会block的系统调用差不多都会调这两个函数，它们就是设个标志而已，比起系统调用自身的操作，比如read socket，便宜多了。
还是用多进程epoll吧。 linux_c_py_php 发表于 2013-02-18 00:02 static/image/common/back.gif
代码为了测试EPOLLONESHOT在多线程环境下的工作状况，结果压力测试所有线程出现频繁的D状态，压力继续提升q ...
梁欧冬？:luya: 没仔细看代码，不过貌似有多个线程在同时epoll_wait。EPOLLONESHOT不知道是什么，不过我实际应用经验中，epoll_wait有且只有一个线程在做的时候会跑得比较好。
如果是LT模式，可以epoll_ctl临时删除相关事件的socket句柄，并把事件交给其他线程做，做完再epoll_ctl回来；ET模式可能没有这个问题，不过貌似会有其他问题，想不起来了。 本帖最后由 yulihua49 于 2013-02-18 10:32 编辑
w_anthony 发表于 2013-02-18 09:20 static/image/common/back.gif
没仔细看代码，不过貌似有多个线程在同时epoll_wait。EPOLLONESHOT不知道是什么，不过我实际应用经验中，ep ...
多个线程在同时epoll_wait是我昨天建议的，他今天就试了。我是LT方式的，大压力测试没问题的。
qps是啥？到多少饱和了？
D状态是啥？ 这是啥分析工具啊.. yulihua49 发表于 2013-02-18 10:11 static/image/common/back.gif
多个线程在同时epoll_wait是我昨天建议的，他今天就试了。我是LT方式的，大压力测试没问题的。
qps是啥？ ...
你直接拉我代码下去看一下吧, 我刚到公司分析一下原因.
qps才13000, 线程频繁D很异常, 就打了一条用来统计qps的日志, 而且没有动态内存分配, 大家帮忙分析一下why吧. pandaiam 发表于 2013-02-18 10:20 static/image/common/back.gif
这是啥分析工具啊..
这个界面叫kcachegrind。