[不懂就问]关于webman和workman的几个问题

0

背景:
传统PHP-FPM已经无法应付当前数据量特别大的今天了。
流量一大,经常遇到PHP-FPM CPU100%的情况,即使堆机器也不是长久解决办法。


准备转型的时候,收集了一下相关资料。
1、转GO
2、基于常驻型的框架
3、PHP8 JIT


1、忽略了,并不是不想转型GO,而是从0开始自己玩玩之类的没问题,但公司基本都是PHP开发的,转GO后大家都没经验遇到BUG也不好解决,而且初识GO,发现packege基本依赖github,国内形势......
2、常驻型
SWOOLE 是一开始的首选框架,通过1周时间熟悉了SWOOLE,但是也发现相关的问题(手册过于简陋、后续测试发现QPS没达到理想数值,某些场景甚至比不上PHP-FPM,最新版。NGINX -> SWOOLE),当然并非引战,也有可能是自己才疏学浅的原因。
webman 次选方案,用了1天时间开发,开发后也进行了测试,发现webman各个方面都超越SWOOLE,甚至说已经超越了当初的理想数值。
!重申一遍,不是引战,业务场合是API接口开发,基本功能涉及鉴权->路由->redis->数据库。由于这里不是框架比较,所以详细的不说太多。如果觉得是1周时间学习swoole不够,那1天学习webman真的也不多。可能某些场景SWOOLE会超过webman,但我需求的场景,确实是webman高出swoole很多很多倍。


[背景信息扯谈完了]
想咨询一下,个人理解,workman针对大型应用各个不同场合都能兼顾到,而webman主要侧重于API的场合,这样理解有错吗?如果是准备转型webman/workman,请问两者的区别是仅仅特定场合不一致吗?性能是差不多的吧?


针对PHP各版本,WEBMAN/WORKMAN是否有相关测试性能?还是说版本对于性能影响是相当小?
比如PHP8开启了JIT,但实际上webman/workman属于常驻型,JIT意义并不大,我可以这样理解吗?


另外想问问,是否能把workman/webman 托管给systemctl?
如生产环境直接用 -d 启用,是否会有守护进程?

已邀请:

weijer

赞同来自:

1、go packege 可以走 https://goproxy.io 跟php composer走代理一样!
2、对于成熟的业务不建议全部重构,可以把瓶颈服务拆出来。php 结合 go 做服务很适合,可以走http协议、也可以走rpc协议。
3、至于workerman和swoole性能上基本上是一个数量级对手,swoole多了协程实现。

evilk

赞同来自:

1.我司大部分业务还是跑在php-fpm上
2.少数需要高性能,高并发的业务,用的swoft(2.0.10) + swoole(4.6.2) + php(7.4)
3.对于用GO重构,根据目前情况来看,当前的架构还可以支撑很久,远远达不到换GO的程度


个人认为:
1.workerman系列和swoole系列,性能应该是一个级别的,差距不会太大
2.workerman系列,本质上讲,还是属于同步模型,一个worker接收了请求,遇到IO,则阻塞在那里,不能继续处理下一个请求
3.swoole 4.x系列,主要归功于协程这个东西,遇到IO,不会阻塞
4.我有考虑,后面的项目用webman试试水,看看效果如何
5.swoole目前的问题是,每次版本更新都会新增功能,修复少数bug,感觉还是不太稳定

要回复问题请先登录注册