一般使用 Laravel 的项目,最开始是享受快速开发,后期数据越来越多,关联关系涉及到的大表之间的 join 操作,路由层面映射关系消耗的时间,会带来很多问题。
着手点主要是:
- 改写 route 缓存及解析方案
- composer 生成的映射文件存放到 apcu 缓存中
- Laravel-stone 或者 Laravel-s 加速,借助 swoole 进行加速
除了 Laravel 自身提供的优化方案及 mysql 慢查询的分析,还有几种较简单可行的方案:
第一种:改写 route:cache
的缓存方案。大多数情况下,项目大了,对应的路由会很多,执行 php artisan route:cache
之后,生成的文件甚至可以在 1M 以上,并发量大了,相当于这个 1M 的文件 I/O 操作也会增多,这种非常拖慢进程,也占用更多内存。对此可以将 route cache 部分的代码拿来本地,改写成一个新的包,可以将 routes 的路由,映射成一个数组,然后 json_encode
一下,或者其他压缩方案,将最终 cache 的文件压缩至越小越好,也要对应是可以高速解析的路由缓存文件。
这个方案,要点是最好经过大量的测试验证,新的 route:cache
和 route:clear
命令,能够应对多种方案的路由缓存和解析(或者在声明路由的时候,就严格约束,允许哪种路由,禁止在路由上使用闭包等),高速解析及压力测试,最终再发布,包代码的后期维护也是一个问题,具体实践再考虑。
第二种:composer 提供了一些参数,在生成项目引用的包映射文件时,借助 php apcu 缓存,可以进一步提升加载的性能。使用 php 自身的缓存机制,而不经过第三方缓存机制,算是一种近距离加速的方案。在 composer install
/ composer dumpautoload
的时候追加参数,如图:
第三种:使用其他开发者的 laravel-stone
或者 laravel-s
这些加速包,借助 swoole 的常驻内存特性,这个配置有点稍微复杂,实际测试情况,在php5.6 的情况下,借助 laravel-stone
加速,提升接近了 100 倍。Laravel-stone
适合在 php7 以下的场景使用,php7 以上的场景推荐 laravel-s
,Laravel Stone 及 Laravel-s
此外,现在还有很多的基于 Swoole 及很类似 Laravel 的框架,例如 Hyperf, Swoft,如果是前期技术选型可以考虑。
从项目管理角度讲:技术实力和测试时间够的话,尝试第一种方案,第二种作为一种辅助,时间不够,可以尝试第三种方案,加深项目组成员的技术实力,甚至可以在一个新项目常识第一种方案,失败或成功都可以让大家学到很多。
如果有哪里有问题,或者有其他方案,请联系:[email protected] ,欢迎讨论。
顺带推荐 质量很高的课程, 欢迎扫码购买
© 原创文章