用 swoole 加速 laravel 似乎并不像宣传的那么有效

2022-05-18 14:10:13 +08:00
 cszchen

因为不止一次听别人讨论要用 Swoole 来提高性能,甚至很多面试官也喜欢问 swoole ,虽然我也觉得 swoole 很牛逼,但是我还是建议不要轻易用,除非你用来做连接池,否则没有什么加速效果。

详细的测试过程我发不在简书,如果觉得测试过程和结果有问题,欢迎理性讨论。
https://www.jianshu.com/p/33a53c574f88

这里直接贴结果
| | Lravel | Laravel + Opcache | LaravelS |
|----------|--------|-------------------|-----------|
| 请求数 | 1000 | 1000 | 1000 |
| 耗时 /req | 42.698 | 4.405 | 1.876 |
| QPS | 23 | 227 | 533 |

乍一看 Swoole (LravelS) 比 Opcache 快了 2 倍多,好像很厉害,但是也只是快了 2.4ms 左右,这只是一个 helloworld 程序,如果多次查询数据库,这个 2.4 ms 可以忽略不计

2308 次点击
所在节点    程序员
18 条回复
reneiw
2022-05-18 14:18:12 +08:00
laravel 自身不是有一个 octane 吗?用那个搭配 swoole
cszchen
2022-05-18 14:23:38 +08:00
@reneiw 理论上都一样,加速效果有限
FrankAdler
2022-05-18 16:18:19 +08:00
真在乎性能,不如加机器、换语言、异步化啥的,我个人也不推荐折腾 swoole ,比直接换语言还费劲,不可控因素还多。
cszchen
2022-05-18 17:23:48 +08:00
@FrankAdler 是啊,有看 swoole 文档的功夫,用 go 或者 node 都做完了
vishun
2022-05-18 17:30:13 +08:00
为什么其他压测 swoole 本身都比 laravels 高 10 几倍?类似
- [Web Framework Benchmarks]( https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=db&l=zijnjz-sf&a=2)
- [Web Frameworks Benchmark]( https://web-frameworks-benchmark.netlify.app/result?l=php)
vishun
2022-05-18 17:30:52 +08:00
而且 workman 比 swoole 快有点吃惊。
luozic
2022-05-18 17:51:30 +08:00
你这几乎就是空对空压测,这么干,测出来有啥意思? 好歹搞个正常的走了 IO 的代码吧。
luozic
2022-05-18 17:54:04 +08:00
sundev
2022-05-18 17:54:19 +08:00
workman 就够了
真要搞协程就该换语言了
iyaozhen
2022-05-18 18:07:14 +08:00
之前用过 swoole 很长一段时间,服务 qps 几万吧

感受就是还是印了那句名言:软件工程没有银弹
swoole 是有好处,但需要你充分理解 swoole 、充分理解 PHP ,很多地方开发的时候瞻前顾后,不适合初级选手。

简单点来说就是你用 golang ,对于新手,你不了解协程也能用,但对于 swoole 你不理解多进程、协程用起来就会各种问题。
FrankAdler
2022-05-18 18:22:50 +08:00
@iyaozhen #10 确实,用 swoole 这种感受很明显
statumer
2022-05-18 18:52:06 +08:00
OP ,不是我打击你,你对统计的理解问题很大。
QPS 这个数据衡量的是 throughput 吞吐量,不是用来衡量 latency 的。不能拿 QPS 来算平均耗时。
当你考虑数据库的连接 latency 为 10ms 的时候,这个数据和你拿 QPS 算出来的“耗时”根本就不能相提并
这就像你上课迟到 1 分钟耽误全班 30 个人不代表你耽误了 30 分钟一样。
搞不懂的话可以看 techempower 的数据。
https://www.techempower.com/benchmarks/#section=data-r20&hw=cl&test=fortune
你要计算 MySQL 查询延迟在整个生命周期的占比的话,原始数据应该是所有 latency 求和取平均。
另一方面,有没有一种可能,数据库连接池化和 swoole 不是互斥关系? swoole 对访问数据库的吞吐量也有同比例提升。
正常情况这两者 throughput 最少有三倍差距。
Kinnice
2022-05-19 06:57:44 +08:00
单看统计来说,如果一个函数时间是 0.1ms ,优化后是 0.01ms 是不是可以说 [忽略不计],尽管这个函数每天会被调用 1 万亿次。
cszchen
2022-05-19 10:49:19 +08:00
@Kinnice 如果是『一个』函数,那这么大的差距当然是质的提升。
cszchen
2022-05-19 10:50:48 +08:00
@luozic 主要是看各种论坛,宣传都是几十几百倍的提升,有点不相信,中午没睡觉搞个测试。
加数据库 IO 的测试确实有必要,但是懒就没弄
cszchen
2022-05-19 10:54:52 +08:00
『有没有一种可能,数据库连接池化和 swoole 不是互斥关系?』
我的理解是 swoole 长主进程,可以维护连接池,为每个请求从连接池分配连接,可以节省部分 IO 时间,所以对吞吐量应该是有提升的,但是我看现在 LaravelS 和 Laravel-swoole 两个扩展并没有使用连接池,所以才不建议用
litguy
2022-05-24 13:34:05 +08:00
延迟 QPS 你搞错了,你把并发度忽略了,别这样算了,你直接测吧
cszchen
2022-05-24 14:02:00 +08:00
@litguy 这个是 ab 的结果,Requests per second 不是 QPS 吗,难道是我理解错了?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/853699

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX