惊群会造成一点资源的浪费,只要经过简单的处理,不会导致任何业务异常。workerman中多个进程/线程尝试去获取客户端链接时,如果发现链接已经被其它进程/线程认领,就什么也不做,没有任何影响。
惊群 简单的说 某个事件发生后,会唤醒多个正在等待该事件的进程/线程,造成一定的cpu资源的浪费
就像一个客人进餐馆吃饭(代表一个客户端链接到来),这时一些休息的服务生(接受链接的进程)看到客人来了赶紧起来去招呼客人,但是一个客人一个服务生就够了,其它服务生看到客人已经被一个服务生抢先认领了,没自己的事情了就又回去休息,造成浪费。
解决办法 通常是通过锁机制等,在任意时刻只让一个进程/线程去接受客户端链接。但是锁机制也会造成cpu等资源的消耗及性能损耗,比起惊群的消耗谁大谁小目前没有一个定论。
目前一些常见的服务器软件有的是通过锁机制来解决惊群的,比如nginx(nginx锁机制默认是开启的,可以关闭);还有一些认为惊群对系统影响不大,没有去处理,比如lighttpd。而apache一般没有惊群效应,apache的进程模型是多个进程阻塞在accept上,目前的Linux内核已经解决了accpet惊群问题(经过本人实际测试确实如此)。
另外也可以通过SO_REUSEPORT选项解决惊群问题。workerman 3.2.1以上版本已经增加了此选项,需要设置worker->reusePort = true来激活。注意:workerman中此选项只在php7有效。
workerman 如同其它服务器软件lighttpd等那样,认为锁机制或者单个进程/线程处理惊群会造成性能的下降,所以没有处理惊群效应。 惊群效应只有在系统负载很低的时候明显,随着系统负载升高惊群效应减弱甚至消失。惊群造成的影响很小很小,相比复杂的业务,影响如同九牛一毛,可以忽略不计。
另外workerman主要是针对长连接应用,惊群只有在建立连接时才会出现,而长连接应用的特点就是不会频繁建立连接,所以对于长连接应用,惊群效应完全可以忽略不计。
nginx 的 epoll 模型是不是就是解决这个问题的啊?
get
惊群会造成一点资源的浪费,只要经过简单的处理,不会导致任何业务异常。workerman中多个进程/线程尝试去获取客户端链接时,如果发现链接已经被其它进程/线程认领,就什么也不做,没有任何影响。
惊群
简单的说 某个事件发生后,会唤醒多个正在等待该事件的进程/线程,造成一定的cpu资源的浪费
就像一个客人进餐馆吃饭(代表一个客户端链接到来),这时一些休息的服务生(接受链接的进程)看到客人来了赶紧起来去招呼客人,但是一个客人一个服务生就够了,其它服务生看到客人已经被一个服务生抢先认领了,没自己的事情了就又回去休息,造成浪费。
解决办法
通常是通过锁机制等,在任意时刻只让一个进程/线程去接受客户端链接。但是锁机制也会造成cpu等资源的消耗及性能损耗,比起惊群的消耗谁大谁小目前没有一个定论。
目前一些常见的服务器软件有的是通过锁机制来解决惊群的,比如nginx(nginx锁机制默认是开启的,可以关闭);还有一些认为惊群对系统影响不大,没有去处理,比如lighttpd。而apache一般没有惊群效应,apache的进程模型是多个进程阻塞在accept上,目前的Linux内核已经解决了accpet惊群问题(经过本人实际测试确实如此)。
另外也可以通过SO_REUSEPORT选项解决惊群问题。workerman 3.2.1以上版本已经增加了此选项,需要设置worker->reusePort = true来激活。注意:workerman中此选项只在php7有效。
workerman
如同其它服务器软件lighttpd等那样,认为锁机制或者单个进程/线程处理惊群会造成性能的下降,所以没有处理惊群效应。
惊群效应只有在系统负载很低的时候明显,随着系统负载升高惊群效应减弱甚至消失。惊群造成的影响很小很小,相比复杂的业务,影响如同九牛一毛,可以忽略不计。
另外workerman主要是针对长连接应用,惊群只有在建立连接时才会出现,而长连接应用的特点就是不会频繁建立连接,所以对于长连接应用,惊群效应完全可以忽略不计。
nginx 的 epoll 模型是不是就是解决这个问题的啊?
get