Accept 惊群现象测试perl脚本

$uname -a

Linux debian-11-34 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux

经过测试Debina 8.0 已经解决了Aceept thundering herd

https://gist.github.com/kazuho/10436253

# 1) run this script with either "accept" or "select-accept" as the argument
# (the script listens to 127.0.0.1:12345)
# 2) telnet localhost 12345
# 3) if you see "accept failed", there is the thundering herd problem
#
#
use strict;
use warnings;
use IO::Socket::INET;

my $mode = $ARGV[0] || ‘‘;
if ($mode !~ /^(accept|select-accept)$/) {
    die "Usage: $0 <accept|select-accept>\n";
}
my $listener = IO::Socket::INET->new(
                                     Listen => 5,
                                     LocalPort => 12345,
                                     LocalAddr => ‘127.0.0.1‘,
                                     Proto => ‘tcp‘,
                                     ReuseAddr => 1,
                                     ) or die "failed to listen to port 127.0.0.1:12345:$!";

if ($mode eq ‘select-accept‘) {
    $listener->blocking(0)
    or die "failed to set listening socket to non-blocking mode:$!";
}
my $pid = fork;
die "fork failed:$!"
unless defined $pid;
while (1) {
    if ($mode eq ‘select-accept‘) {
        while (1) {
            my $rfds = ‘‘;
            vec($rfds, fileno($listener), 1) = 1;
            if (select($rfds, undef, undef, undef) >= 1) {
                last;
            }
        }
    }
    my $conn = $listener->accept;
    if ($conn) {
        warn "connected!";
        $conn->close;
    } else {
        warn "accept failed:$!";
    }

}

时间: 2024-10-13 04:05:06

Accept 惊群现象测试perl脚本的相关文章

Nginx如何解决“惊群”现象

首先解释下什么是"惊群"现象:如果多个工作进程同时拥有某个监听套接口,那么一旦该套接口出现某客户端请求,此时就将引发所有拥有该套接口的工作进程去争抢这个请求,能争抢到的肯定只有某一个工作进程,而其他工作进程注定要无功而返,这种现象即为"惊群". Nginx解决这种"惊群"现象使用的是负载均衡的策略,接下来先结合Nginx的源码详细介绍下Nginx的这种负载均衡策略. 首先是Nginx如何开启负载均衡策略:当然运行的Nginx要是多进程模型,并且工

Nginx中的惊群现象解决方法

*什么是惊群现象?Nginx中用了什么方法来避免这种问题的发生?本篇就解决这两个问题...→_→* 惊群现象的定义与危害 在Nginx中,每一个worker进程都是由master进程fork出来的.master进程创建socket后进行listen.bind操作,fork出来的worker继承了socket,调用accpet开始监听等待网络连接 如果这时有多个worker进程都在等待事件的发生.当事件发生时,这些worker进程被同时唤醒,但最终只有一个worker进程可以处理事件成功,其他的w

Redis 利用锁机制来防止缓存过期产生的惊群现象-转载自 http://my.oschina.net/u/1156660/blog/360552

首先,所谓的缓存过期引起的“惊群”现象是指,在大并发情况下,我们通常会用缓存来给数据库分压,但是会有这么一种情况发生,那就是在一定时间 内生成大量的缓存,然后当缓存到期之后又有大量的缓存失效,导致后端数据库的压力突然增大,这种现象就可以称为“缓存过期产生的惊群现象”! 以下代码的思路,就是利用“锁机制”来防止惊群现象.先看代码: class KomaRedis{ private $redis; //redis对象 private static $_instance = null; private

pthread_cond_signal惊群现象

1.如下代码所示: #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <pthread.h> pthread_mutex_t count_lock; pthread_cond_t count_ready; int count; void *decrement_count(void *arg) { while(1) { pthread_mutex_lock(&coun

2、惊群现象

参考文献有 1:https://blog.csdn.net/russell_tao/article/details/7204260 2:https://www.jianshu.com/p/8f362e943e56 什么是“惊群”? 多线程/多进程(linux下线程进程也没多大区别)等待同一个socket事件,当这个事件发生时,这些线程/进程被同时唤醒,就是惊群.可以想见,效率很低下,许多进程被内核重新调度唤醒,同时去响应这一个事件,当然只有一个进程能处理事件成功,其他的进程在处理该事件失败后重新

accept与epoll惊群 转载

今天打开 OneNote,发现里面躺着一篇很久以前写的笔记,现在将它贴出来. 1. 什么叫惊群现象 首先,我们看看维基百科对惊群的定义: The thundering herd problem occurs when a large number of processes waiting for an event are awoken when that event occurs, but only one process is able to proceed at a time. After

linux 惊群问题

1. 结论 对于惊群的资料,网上特别多,良莠不齐,也不全面.看的时候,有的资料说,惊群已经解决了,有的资料说,惊群还没解决.. 哪个才是对的?!  一怒之下,在研究各种公开资料的基础上,特意查对了linux源码,总结了此文.希望对有需要的人略有帮助,希望各位大神轻拍,如有错漏,不吝指教,感激不尽.([email protected]) 先说结论吧: 1. Linux多进程accept系统调用的惊群问题(注意,这里没有使用select.epoll等事件机制),在linux 2.6版本之前的版本存在

Linux网络编程“惊群”问题总结

1.前言 我从事Linux系统下网络开发将近4年了,经常还是遇到一些问题,只是知其然而不知其所以然,有时候和其他人交流,搞得非常尴尬.如今计算机都是多核了,网络编程框架也逐步丰富多了,我所知道的有多进程.多线程.异步事件驱动常用的三种模型.最经典的模型就是Nginx中所用的Master-Worker多进程异步驱动模型.今天和大家一起讨论一下网络开发中遇到的“惊群”现象.之前只是听说过这个现象,网上查资料也了解了基本概念,在实际的工作中还真没有遇到过.今天周末,结合自己的理解和网上的资料,彻底将“

epoll惊群问题-解决思路

[遇到问题] 手头原来有一个单进程的linux epoll服务器程序,近来希望将它改写成多进程版本,主要原因有: 在服务高峰期间 并发的 网络请求非常海量,目前的单进程版本的程序有点吃不消:单进程时只有一个循环先后处理epoll_wait()到的事件,使得某些不幸排队靠后的socket fd的网络事件处理不及时(担心有些socket客户端等不耐烦而超时断开): 希望充分利用到服务器的多颗CPU: 但随着改写工作的深入,便第一次碰到了“惊群”问题,一开始我的程序设想如下: 主进程先监听端口, li