[不懂就问]关于webman和workerman swoole的几个问题
背景：
传统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 启用，是否会有守护进程？
1、go packege 可以走 https://goproxy.io 跟php composer走代理一样！
2、对于成熟的业务不建议全部重构，可以把瓶颈服务拆出来。php 结合 go 做服务很适合，可以走http协议、也可以走rpc协议。
3、至于workerman和swoole性能上基本上是一个数量级对手，swoole多了协程实现。
感谢回复
1、GO基本忽略了，原因除了国内网络外，最主要的是公司没有使用GO的熟手，怕遇到问题后“无解”，这是公司自身原因，并非语言原因，另一点是看过多个评测，workman性能都追上GO了（没具体测试）
2、其实现在观察了下业务性能，基本瓶颈是在于MYSQL->流量压力->fpm处理能力
MYSQL部分只能通过mysql语句优化和尝试释放出mysql，早期项目大部分功能是通过SQL实现的，现在看能否通过业务层实现。
流量压力其实也没更好的解决方法，只能通过加大带宽来避免。
fpm压力，其实现在流量一大，fpm基本就100%，后续请求都直接500.
现在暂时能想到的方法就是把数据库中账号，汇率等变化频率低的信息load到业务层中，减轻数据库压力。产品变动价格变动仓存变动等通过丢进rabbitMQ，在另一台机进行消费，把同步改为异步，释放主业务服务器压力。
*现在其实最大瓶颈是在于当初由于业务原因，要弄两个功能一样，数据隔离的系统。当初做法就是整个数据库复制一份，架构同步，数据隔离。后期因为两个系统都需要对外提供服务和产品查询，变成了现在前端接口特别是要分页的那些，SQL语句根本无法优化，必须两边全量查询后才能分页。暂时都是用redis来解决。
3、workerman和swoole性能是否接近估计看场景吧，而且就算接近，workman的社区和手册比swoole的环境好很多。实话实说，swoole 4.4版本 + PHP 7.2，使用了swoole内置的数据库连接池，提供API服务；测试结果是QPS极低，唯一定位到的就是只要查询mysql，qps就会降低，当时尝试直接使用PDO，开启(全)协程，使用官方连接池，结果都一样。后来换了webman，qps马上就上来了；具体什么原因不清楚，也没深究。
最后，我这个只是自己业务上测试结果，是否因为某些原因导致swoole如此，不清楚，更加不能作为性能论证，我也没有贬低swoole的意思，只是在我个人的业务场景上数值如此。不具备参考性。任何开源框架都值得尊重。
swoole与wk的性能应该是差别不大，出现这个结果可能是你的测试姿势不对。你的这个问题的原因有可能是数据库链接池开的数量大了导致性能消耗而下降的，当然这个只是猜测的原因。具体还要看你的测试逻辑
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,感觉还是不太稳定
说实话，我是6年多前注意到workman的，
但是同期也发现了swoole，两边都没太深入接触，仅仅看了下而已。
到最近遇到瓶颈了，打算改变架构，才开始深入了解这两样产品。
我一开始认为swoole怎么也比workman强,主要原因是因为swoole是C++开发的扩展。
但是实际情况，从各方面第三方压测结果，workman是超越swoole。
但当时我依然不相信，觉得评测有猫腻，
后续实际项目中，现在有一个服务（微信导购客服）是用swoole开发的，并且已经稳定运行了1个多月，
现在要增加API接口，第一反应就是swoole，
但开发完了权鉴，列表的接口后，用wrk进行压测，结果令我目瞪口呆，是比FPM还低下。
机器配置是（4C 8G 5M），在运行的服务有rabbitMQ，nginx，php-fpm，swoole 导购，
新增这套的api流程是NGINX->SWOOLE，然后异地进行wrk压测。（当时能试的都试过了，文档翻阅无数遍，数据库框架从原生PDO换swoole 数据库池）结果差异不大，
我尝试过取消所有DB操作，压测结果会飙升，涉及到DB，结果狂降，
当时尝试过在mysql 里show process，但是数据库基本没压力。倒是主机的CPU直接400%。
后来更换了workman，完成了鉴权和列表API后，压测结果和CPU使用率对比swoole简直是天地之壤。
这就是我换成workman主要原因，次要原因是swoole社区支持比较差，文档也.....
当然，我觉得应该是我服务器上环境的原因导致这个结果的，
但无论如何，我已经放弃了swoole了。
不过怎么说，这两个框架无疑都是最后的一道曙光。
swoole慢慢向商业演变，workman依然坚持社区维护。而且回复都非常及时，这个是我当时没想到...
不说太多了，选择哪个估计看自有业务吧，我也不是吹捧workman，毕竟没必要在workman的论坛里吹捧workman。但workman作者的这份精神，真实十分难能可贵。
作者的开源精神是大大的好啊
看到这篇文章，您的经历在我身上重演，你所表达的所有流程以及想法，跟我完全一样。一样的业务逻辑swoole/webma压测后，webman完胜。哈哈哈我也没有要黑swoole的意思（可能跟我对代码水平有关）