【实测比较half-sync-half-async模式与leader-follower模式的性能与场景(直播)】

linux_c_py_php

yulihua49 发表于 2013-02-16 15:42
没明白。
据我试验，多个线程在epoll_wait的时候，其它多个线程是可以同时或不同时（不使用任何互斥锁） ...

应用层的leader-follower肯定要自己做, epoll只是检测event的一个API, 为什么你们的程序可以无锁epoll_wait? 我认为这是不可能的, 肯定是只有Leader才可以epoll_wait, 你没看清楚你们的代码吧, 要么就是每个线程一个独立的epoll各自维护一批fd.


再有一个问题就是, epoll_wait的同时, 另外一个线程epoll_ctl, 这件事是线程安全的, 这个线程安全的概念是否能做到这个效果: A线程epoll-wait, 但没有任何事件发生并挂起, B线程epoll_ctl恢复一个fd的监听, 并且fd立即可读/可写, 你们知道epoll_wait能否监听到这个事件吗? 有这个试验吗?

linux_c_py_php

yulihua49 发表于 2013-02-16 17:52
前边说了，不会发生这种情况。
epoll_wait确实是防惊群的。
前边的话，没有贬义，请多包涵。

原因是什么? 求详解.

yulihua49

linux_c_py_php 发表于 2013-02-16 17:56
再有一个问题就是, epoll_wait的同时, 另外一个线程epoll_ctl, 这件事是线程安全的, 这个线程安全的概念是否能做到这个效果: A线程epoll-wait, 但没有任何事件发生并挂起, B线程epoll_ctl恢复一个fd的监听, 并且fd立即可读/可写, 你们知道epoll_wait能否监听到这个事件吗? 有这个试验吗...

试过了，不仅试过了，而且已经在应用了。没问题的。

linux_c_py_php

linux_c_py_php 发表于 2013-02-16 17:56
原因是什么? 求详解.

千万别告诉epoll_wait在多线程使用时将FD=A可读告诉线程1, 过一会就不会再告诉线程2了, epoll_wait自己不惊群可以理解, 但epoll_wait到你epoll_ctl移除监听中间不是原子的, 为什么不可能发生两个线程同时检测到事件?

linux_c_py_php

yulihua49 发表于 2013-02-16 17:58
试过了，不仅试过了，而且已经在应用了。没问题的。

有没有理论依据啊, 这太假了, 不能信服

yulihua49

linux_c_py_php 发表于 2013-02-16 17:56
原因是什么? 求详解.

在一个项目开始之前，确实有这个疑惑。
第一个版本就是一个线程监听，把事件分配给线程池。
发现瓶颈竟然在分配线程，要经过一些条件判断再分配，这个过程单线程的。
当我们的吞吐量达到2.5W/S左右时，饱和了。
这时问题是，把分配过程多线程化。最担心的，就是你说的这个问题。
当年进行了大量的试验，包括压力测试。
最后确认了，epoll，多线程安全，对事件队列的控制完整、准确，不惊群。
新的方案，群狼抢奶，实施了，吞吐量达到了6.5W/S,并且未饱和，还有余地。
至于理论根据，我不清楚。但我不认为理论方面会出现什么问题，仅仅是操作问题，把事件的互操作处理好了而已。

linux_c_py_php

linux_c_py_php 发表于 2013-02-16 17:56
应用层的leader-follower肯定要自己做, epoll只是检测event的一个API, 为什么你们的程序可以无锁epol ...

从那个帖子里看, epoll_ctl是线程安全, 并且可唤醒epoll_wait的, 这下做LF省事了.

那么就剩下epoll_wait的问题了.

linux_c_py_php

嗯, 接下来用libev了.

windoze 发表于 2013-02-16 14:55
第2条可以开一个per-connection memory pool，STL那些容器加个allocator就差不多了。
如果还在用C++03，可 ...

linux_c_py_php

@windoze 大侠,

要你做LF的话, 还是需要做cond+mutex抢Leader后做epoll_wait, 监听到event后epoll_ctl移除fd监听, 然后放掉cond转为follower开始read/write/process, 最后epoll_ctl恢复fd监听, 抢cond+mutex做leader.

这个过程**什么影响性能的位置吗.  

  我主要犹豫follower的任务里是否应该包括read/write, 从理论上来讲, 由follower做read/write会提高并发I/O能力, 比leader做I/O(意思就是Leader根据事件做读写, 如果是读并且解析到至少一个请求, 则转为follower)要更高效.

linux_c_py_php

yulihua49 发表于 2013-02-16 18:01
在一个项目开始之前，确实有这个疑惑。
第一个版本就是一个线程监听，把事件分配给线程池。
发现瓶颈竟 ...

意思就是N个线程, 共享一个epoll实例, 然后都调用epoll_wait, 然后每个线程分到的event fd都不一样, 并且你慢慢悠悠的在线程A里read fd=5, epoll_wait过24小时之后也会保证这个fd不会通知给线程B, 从而保证线程A与线程B不会发生同时的慢慢悠悠的read吗 ?

unbelievable啊