webman真的有优势吗 ?

汹涌的小草 更新于2021-08-13

大多数三方lib的底层IO都是采用阻塞式运行的, 这样一来性能不是又被拉下去了吗 ?

一个阻塞直接把当前进程的事件循环都阻塞了, 同一进程下的连接必然要受到连累, 即使开多进程也不能从根源上解决这个问题, 阻塞还是会存在

既然直接用阻塞的第三方组件那么为什么不直接使用 fpm+op 呢 ? 省心省力还高效

好奇, 作者会用 webman 去写企业级应用吗 ?

 7202  3 0

3个回答

six 2021-08-09

基于fpm的框架性能比webman差很多吧，看下 https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=db&l=zik073-sf 压测对比。slim应该算是fpm框架里比较快的轻量框架了，同样的数据库查询业务，webman比slim快十多倍。我想应该是webman常驻内存，数据库连接什么的可以一直复用，性能才如此出色。

我的理解是如果你的业务不需要特别高的性能，那么基于fpm的框架就足够了。
如果业务请求量很大，需要高性能，可以把fpm的业务迁移到webman下，
切换成本也很低，因为基于webman和基于fpm下开发体验基本没差别。

至于你说的阻塞，我觉得webman目前是靠多进切换程来解决的，如果阻塞较多，就要多开进程。
不清楚后面会不会采用php8.1自带的协程。不过支持协程后开发难度肯定是有上升的，
之前基于fpm下写的代码和类库基本上都无法直接用了。

webman群里看到已经有很多人用在正式环境了。

汹涌的小草 2021-08-10

没有异步IO支持性能应该过不了关, 至于为什么压测会高这个就需要分析了, 就比如多线程读写磁盘和单线程读写磁盘场景, 由于磁盘只有一个本质上还是磁盘在串行读取, 但不可否认的是, 异步要比同步快, 发送100个请求出去, 单次请求1s, 如果采用异步可能1~2s 就完成了, 采用同步阻塞则需要100S +, 这样的场景是不是被拉到和fpm一个级别去了 ? 协程也只是让函数能暂停和恢复, 并不能让同步阻塞操作变成异步非阻塞, 正是有了协程的支持, 才能屏蔽掉异步和同步的编程差异
nitron 2021-08-11

@8086:Webman使用起来基本跟fpm的编码方式没太多区别,学习成本较低,但是收益明显,
swoole这种引入太多自己的东西,成本及收益不成正比,说去zz不正确的话,有这时间我还不如去用go?
喵了个咪 2021-08-13

webman对比php-fpm的优势就是快，qps能高10倍左右。实际项目测试对比过。