站在巨人的肩膀上，通过 Swoole 加速 Laravel/Lumen

[hhxsv5]

背景：公司严重依赖 Laravel 和 Lumen 框架，显暴露出来了性能问题。

解决：站在巨人的肩膀上，通过 Swoole 加速 Laravel/Lumen 调研了目前已有的 Laravel+Swoole 结合方案，多多少少都有点儿问题，有的定制化太强，有的没有再维护了。于是决定再造此轮子。

成果： LaravelS https://github.com/hhxsv5/laravel-s 通过 Swoole 来加速 Laravel/Lumen，常驻内存，内置 HTTP 服务器，平滑 Reload，与 Nginx 配合搭建高可用分布式服务器群，开箱即用。

目前已经在公司生产环境用起来了，后面考虑加入连接池和协程客户端的封装。

有需求的可以尝试下，Give me star

[hhxsv5]

CookieQueue 坑已填

[xwsoul]

666 先 Start 一个

[hhxsv5]

@xwsoul 谢谢，人多力量大

[lbp0200]

多少并发遇到性能问题？

[hhxsv5]

@lbp0200 主要是请求的响应时间，fpm 下 laravel 不管再怎么优化，hello world 也要 100 多毫秒；整体并发量不高，每天 pv600w 左右，高峰期也就并发 200 左右，fpm 下压测 laravel 并发就在 300 左右(4 核 8G)，但接口的平均响应时长已经超过 1 秒了。

[hhxsv5]

@lbp0200 laravel 代码一行不改的情况下，用 swoole http server 后，hello world 从 100 多毫秒降到 30 多毫秒，前端再用 nginx 代理下，最多 40 毫秒。

[lyhiving]

要突破瓶颈 laravel 框架还是要改，router 这个还有很多优化的地方

[hhxsv5]

@lyhiving 对，特别是路由几百个的，qps 急速下降。

[tabris17]

这种奇技淫巧我是不太看好的。要么打补丁，要么有各种限制

[hhxsv5]

有个小伙伴还做了一次调优的记录 https://segmentfault.com/a/1190000011569012，
总结下，
提升明显的几个操作：
1. 删除多余中间件
2. 开启类映射加载优化 php artisan optimize --force
3. 缓存路由 php artisan route:cache
4. 开启 opcache

其他的，比如配置缓存，关闭 debug 能做就做。提升一点是一点。

[hhxsv5]

@tabris17 😆 能抓到耗子的猫就是好猫，像我们公司重度依赖 laravel 的，老项目一堆都是，重写难度太大，老板也不会给那么多时间的。 所以开启新项目前还是得规划好，要是重来的话，可能就是 go 搞服务层，php 搞业务层。

[Outshine]

@hhxsv5 hello world 都要 100ms ？为啥我读取了数据库都才 30+ms （版本 5.5，启用了 config:cache 和 route:cache，并开启了 Opcache ）

[MeteorCat]

问题本身在于 laravel 上，说实话，laravel 在量上来之后那性能真的惨不忍睹，特别是用来做 API 接口服务，总体来说实在太重了

[hhxsv5]

@Outshine Laravel 默认情况下测得，没有做任何的优化

[server]

先来波👍。真的要性能还是选择 go。swoole 快在于异步，php 得加 yield，不然一个 file_put_contents 直接凉凉。
swoole 2+ 支持协程，官方也有 redis mysql https://wiki.swoole.com/wiki/page/749.html，如果你要想增加其他的就得想办法了。

[sodowe666]

用毛的 laravel yii2 比他强多了

[abusizhishen]

先 star 为敬

[eslizn]

有遇到 di 的问题吗？之前用 swoole 的时候踩了 call_user_func_array 的坑，印象中 di 是肯定需要这个的

[hhxsv5]

@sodowe666 主要是老项目了，重构搞不动

[hhxsv5]

@eslizn 要用 Coroutine::call_user_func_array