webman采用阻塞worker模式运行为什么性能还这么高？

每次请求都是一个独立进程，为什么不可以呀？

难受，是阻塞的呀，就是你开500进程 最多就是接受500个请求，现在webman 有协程加持 可以处理请求第三方请求阻塞问题了

1. fpm开500个进程，每个进程是独立的，不会受其他进程的影响，而worker的这种模式是复用worker，所以会造成worker进程本身的阻塞，这是两码事。

2. “webman 有协程加持，可以处理请求第三方请求阻塞问题了”，5.0我看过了，目前还没有发布正式版本。但真实业务中不单单是请求第三方curl，每一个可能存在耗时(IO、cup密集计算等)的操作都会出现以上阻塞情况。

fpm是阻塞处理，虽然可以设置动态进程数，但也并不是一个请求创建一个进程。现在基本没有一个请求创建一个进程的服务器软件了，因为那样性能极低。

webman支持fiber协程调用第三方接口，第三方接口慢不会阻塞业务。
另外看了下源码，webman也支持swoole/swow作为驱动，应该可以使用swoole或swow的协程。

fpm是同步处理没有问题，但是我的意思是它的每一次请求都是在一个独立的进程内完成的，所以不会因为当前的进程没有处理完成而导致其他进程出现阻塞请求(前提未达到设定的最大进程数量时，因为这又是另外一个概念了)，可能我描述的概念不够清晰，总之一个复用进程，一个独占进程。

那么就目前而言，webman这个机制处理一些io操作确实不如swoole这种非阻塞的模式合适。。

fpm也一样，100个进程，瞬间第101个请求过来时也是在排队阻塞等待处理，这和webman没有多少区别。
webman本身io处理机制和swoole是一样的，都是基于event-loop加非阻塞IO，差别也不大。但是webman身为php层面的框架无法改变PHP内置函数(如PDO)的IO接口阻塞问题，而swoole作为扩展可以hook这些阻塞接口变成非阻塞。区别实际在于这里。说得通俗一点，webman本身的IO是异步非阻塞的，但是业务代码可能是阻塞的。

另外webman本身也支持swoole驱动，可以hook PHP内置的IO接口，达到非阻塞调用，但是带来的负面影响就是和swoole一样，需要管理上下文。

OK，学习了

@six 专业

你把Webman当成不需要每次请求都冷启动一次框架代码的FPM(近似)就好理解了

讲解很详细，其实异步并行能够更充分的利用服务器资源，达到一个比较高的处理效率~

多线程在这里只是在同/异步角度上解决高并发问题的其中的一个方法手段，是在同一时刻利用计算机闲置资源的一种方式。多线程在解决高并发问题中所起到的作用就是使计算机的资源在每一时刻都能达到最大的利用率，不至于浪费计算机资源使其闲置。

是的，单线程异步就需要利用事件循环，本质上可以看作是一个消费者，通过自己的规则来进行消费