上半年把公司的项目用 Laravel 重构了一把,下半年流量大了之后线上 CPU 狂报警,网上都说 Laravel 慢的不行,求问有经验的大神,Larvael 到底能慢到什么程度,心里好有点谱。
感觉又要重构了,😭😭😭!
UPDATE:
刚才找了一台机器压测了一下,就一个 echo time();
原生php
TP
Laravel
哎,不说了,滚去老老实实重构了。
程序员就不应该只图自己一时爽啊。
两年了,看到还有人收藏,回来补充一下,结论就是,laravel 确实很慢,高流量业务千万别用,我们的业务已经基本都迁移了,期间遇到的坑在这里写一下:
路由,众所周知,Laravel 的路由组件是出了名的慢,主要是用反射之类的东西(具体原理记不清了,总之就是很慢)。
Eloquent,虽然提供了很方便的数据库操作接口,但是每次 new model 的时候,如果有 fillable 的属性,他会把所以的字段都给你填充一边,这样在循环中,或者大流量下,瞬间对系统资源的占用是很大的。
Guzzle http client,实际测试过使用这个 client 发起多次 http 请求,几乎所有的对象都不会复用(猜测),所以导致期间进行的内存分配和 new 对象的次数,比随手用 curl 写一个 client 要多上万倍。
总结来讲就是 Laravel 在对象的创建和内存的复用方面,是很奢侈的,而且一个请求下来,会经历无数的没什么用的操作,对于资源是一点也不节省。
以上,基于之前提问是 5.6.5 版本,这两年来我们团队填坑发现到的一些问题,最新版本的再没有研究过,总之就是用 PHP 写东西还是按需获取资源,能少调用一次函数就少调用一次,能少 new 一个对象就少 new 一个,浪费可耻,也慢。
最后,这些都属于回忆的时候写的,有些细节可能不尽准确,大概方向就是这些。
具体查问题的办法就是使用性能采集扩展,目前支持 php 7 的有 php-xhprof-extension , 也可以参考这个扩展自研,满足自己的采集需求,查看自己的代码在执行过程中对内存的申请、CPU 的占用等信息,便可知道慢在哪里了。
1
mchl 2018-01-04 19:44:34 +08:00 via iPhone
搜 laravel opcache
|
3
kslr 2018-01-04 19:45:59 +08:00
最近关于 PHP 的帖子都是招黑啊
|
4
kslr 2018-01-04 19:46:29 +08:00
CPU 报警找到原因了吗?
|
5
akira 2018-01-04 19:48:18 +08:00
先确认是什么地方出现瓶颈吧。
|
6
Tairy OP @kslr 还没查到确切的原因,用 ab 测试了一下 laravel 和别的框架,输出同样的内容 laravel 的表现堪忧啊。
|
7
flyingghost 2018-01-04 19:50:53 +08:00
@akira 请教如何找瓶颈?
|
8
Tairy OP @akira 能想到是瓶颈的地方都试过了,发现改了之后也没啥明显优化,现在唯一能想到的就是可能 Laravel 的性能真的不行。
|
9
assad 2018-01-04 19:52:06 +08:00 via Android
这个框架性能上确实堪忧
|
11
kslr 2018-01-04 19:55:23 +08:00
真的是招黑啊,只懂得使用,其他什么都不知道,不知道该如何讲起。建议你先做好系统监控吧,打好日志。
解释的话真的是一点意思也没有了。 |
12
guoer 2018-01-04 20:00:40 +08:00 via iPhone
xphrof
|
13
gclove 2018-01-04 20:05:31 +08:00
慢是相对来说的, 说不慢的都是再讲 违心的慌
建议开启 opcache 然后, 缓存自动加载 composer install --optimize-autoloader 缓存配置(当然你要修改配置, 必须清除缓存) php artisan config:cache 缓存路由 php artisan route:cache ==== 然后你看看你不是有过多的数据库查询 ? 能不能加索引, 或者 脱离数据库 使用缓存, 消息队列 解决 |
14
terranboy 2018-01-04 20:06:05 +08:00
流量大了 压力根本就不应该在 PHP 上面吧 NGINX 和 Redis 等才是承载压力的主力 如果是 那就是架构问题了
|
15
gclove 2018-01-04 20:09:09 +08:00
其次是看, PHP 版本, 系统版本, 服务器性能,磁盘性能,网络健康状况 这些
我用 Laravel 做过 100w pv 的项目。 当然,你要看流量峰值的 |
16
des 2018-01-04 20:21:18 +08:00 via Android
优化了之后没有明显改善?
感觉不是框架的问题。 如#12 楼所说,上 xphrof |
17
lianyue 2018-01-04 20:24:25 +08:00
php 慢 做集群 😂
|
19
qiayue 2018-01-04 20:25:41 +08:00
数据库加索引没有?
|
22
zn 2018-01-04 20:30:06 +08:00
哈哈,重构换用 symfony 4 吧骚年,全宇宙最快的重量级 PHP 框架之一哦。
|
23
tomczhen 2018-01-04 20:32:47 +08:00
毫无营养的问题,换成任意一种框架和语言都行。
架构,业务规模,初步性能分析,监控数据、日志,就这些都没有,难道靠“感觉”优化吗? |
26
TangMonk 2018-01-04 20:39:10 +08:00 via Android
每秒 3000 已经很不错了好吧,还嫌不够就集群啊
|
29
Tairy OP @TangMonk 数据库层倒是没多大问题,因为我们搜索业务比较重,所以大量的查询都走到搜索引擎,这块用的是阿里云的 OpenSearch,猜想可能是瓶颈之一。
|
30
TangMonk 2018-01-04 20:47:54 +08:00 via Android
@Tairy 你给服务器装个 APM 监控一下性能试试,用国外的 newrelic 或者国内的 OneAPM,可以看到很详细的性能数据
|
31
nicevar 2018-01-04 20:49:17 +08:00
刚给公司解决了瓶颈问题,重点还是数据库查询这一块,榨干每一个地方,用重型框架就是这样,业务没上来的时候看似没什么问题,一旦上来了问题就凸显出来了,加上有些同事写代码的时候不考虑性能,为了省事用现成的查询封装就为了取一两个字段而不去重新写查询逻辑,非常浪费资源
|
33
l57t7q 2018-01-04 20:57:51 +08:00 via Android
我这里 api 日访问量大概有 800w,单机无压力
|
35
ghostsf 2018-01-04 21:03:05 +08:00 via Android
既然集群,索引,缓存都搞了,那么主要就是要 review 代码,优化数据库操作了。检查下代码里,哪里处理数据,查询数据库很慢,然后拿出来分析优化下。
|
36
defunct9 2018-01-04 21:04:14 +08:00 via iPhone
开 ssh,上去看看👀
|
37
deepkolos 2018-01-04 21:05:17 +08:00
xdebug 有可以找性能瓶颈
|
38
MeteorCat 2018-01-04 21:16:17 +08:00 via Android
这框架就这样,排查下是不是数据库问题,select 是不是没用的都给*查询出来,还有看下第三方是不是加载过多了,这框架量小没啥问题,量大的时候分分种让你哭死
|
39
Fishdrowned 2018-01-04 21:16:42 +08:00
让我告诉你 laravel 是怎么慢的,以及我是为什么抛弃它的:
https://github.com/phwoolcon/phwoolcon/wiki/%E4%B8%BA%E4%BB%80%E4%B9%88%E8%A6%81%E5%BC%80%E5%8F%91-Phwoolcon |
40
dryyun 2018-01-04 21:20:01 +08:00
所以,换个框架吧。
|
41
Xrong 2018-01-04 21:22:26 +08:00
看看卡在哪个 SQL 上吧
|
42
Fishdrowned 2018-01-04 21:23:19 +08:00
Laravel 慢不是什么地方出瓶颈了,而是 Laravel 这个框架本身就是瓶颈。
优化点: 1. 重构 router,特别是你的路由比较多的时候,foreach 之后还要正则就是找不痛快; 2. 用 swoole 服务模式把需要重复初始化的地方抹平,只初始化一次,不过这个会进入普通 php 程序员不熟悉的领域,而且大部分业务逻辑以及第三方组件需要修改以适应服务模式; 3. 放弃 Laravel |
43
guoer 2018-01-04 21:23:27 +08:00 via iPhone
单台 3k 吗? 先多开几台 php 机器看看。
xhprof 有工具可以生成图的,多搜索下。 这是个成长的好机会。好好把握 |
44
lifeintools 2018-01-04 21:39:16 +08:00
羡慕这种机会。。
|
45
Veigar 2018-01-04 22:05:00 +08:00
Go 最慢的 beego + redis 2 核 2G 垃圾云 单台 7k
|
46
darluc 2018-01-04 22:44:15 +08:00
@Fishdrowned 这个想法不错 swoole + phalcon
|
47
dawniii 2018-01-04 22:48:40 +08:00
|
48
dawniii 2018-01-04 22:57:21 +08:00
|
49
zqhong 2018-01-04 23:35:52 +08:00
|
50
cjyang1128 2018-01-04 23:52:35 +08:00
先看懂 xhprof 再说吧。。
|
51
957204459 2018-01-05 09:16:23 +08:00
话说真没感觉到慢
|
52
lalala121 2018-01-05 09:17:31 +08:00
symfony 在向你招手
|
53
TypeErrorNone 2018-01-05 09:38:52 +08:00
你机器的配置是什么?
|
55
freeminder 2018-01-05 09:59:24 +08:00
之前的项目是 yaf 的路由+laravel 的 orm,离线部分利用了 laravel 的 schedule 和 artisan,之后看性能 laravel 主要在 ORM 的部分了,序列化真的要调用好多层
|
56
scofieldpeng 2018-01-05 10:20:02 +08:00
话说前几天我司外包组的接了一个维护投票的活,上家坑爹给人家在千万云上买了 8 核 16g 内存,这就算了,带宽直接撸了 200 兆,php 写的太差,几千就把 php 进程干掉了,nginx 加缓存,php 跑了多个进程,依然扛不过刷票的那帮土匪,然后,我用 golang 把核心重撸了一个,从此天下太平,所以楼主,要不换下语言? 2333
|
57
jhdxr 2018-01-05 10:20:07 +08:00
laravel 性能的确不是那么好,毕竟遍地匿名函数,但测也不是你这么测的,laravel 是一个默认开启 session 的框架,而其他框架或者原生你压测是没有的,这个不用说在网上,在 V2EX 上也已经有无数人测过然后被指正过了
然后你这个帖子通篇没有任何信息量。CPU 狂报警,那什么程序在那吃 CPU 你看了吗?如果看下来是 MySQL 占用高,那多半是 SQL 没写好(哪怕用了 ORM,最终也会生成 SQL );如果是 PHP-FPM,那的确就是得优化 PHP 代码了(然而你并看不懂 xhprof _(:з」∠)_) 总觉得 PHP 日常被黑,面向 google 编程你早晚遇到瓶颈,只是来的或早或晚而已。 |
58
wekw 2018-01-05 10:20:20 +08:00
CPU 报警真是奇怪。。。。一般都是数据库优化不到位,内存爆炸,响应时间大幅增加。
|
59
Tairy OP @jhdxr 真的不是黑 PHP,就是提出个疑问而已,我已经在抓 xhprof 研究了,占用 CPU 的就是 fpm,MySQL 是独立的主机。
|
60
kkeiko 2018-01-05 10:31:54 +08:00
laravel 本身是不错的框架,和其他框架比,慢也是事实,但同时开发更优雅,解耦更强也是事实。根本上还是要看使用者要的是什么,但有一点可以肯定的是,从来没有万能的框架,laravel 也是如此,技术架构是要不断迭代更新来适应业务的。而不能说 laravel 在这个时间节点不适应你的业务就是不好的。
|
62
keikeizhang 2018-01-05 10:37:19 +08:00
Yaf 你最佳的选择
或者直接 JAVA 我们公司用 Lumen 开发 API |
63
kimmykuang 2018-01-05 11:03:49 +08:00
不要用 fpm 模式啊
|
64
st2udio 2018-01-05 11:24:22 +08:00
我上次开了 800 个 fpm 进程,跑 laravel
|
65
YMB 2018-01-05 11:33:55 +08:00
你们没管架构的吗。。。组长。。总监之类的。。。
模块化啊。。模块间 API 通讯。。无敌的。。 阿里有些架构就这么干的。。 |
68
sampeng 2018-01-05 13:42:11 +08:00
加机器啊。。。。。能用机器解决的问题。干嘛用人来解决。程序员一年工资 10-30 万。一台机器一年才多少钱。。。
|
70
wekw 2018-01-05 15:19:28 +08:00
@Fishdrowned 老实说你的回复是这么多回复中最没价值的,因为一看你就没用你所说的这个架构做过任何一个生产环境的项目。用过 phalcon 的人都会吐血的。
|
71
zzWinD 2018-01-05 16:17:07 +08:00
@Veigar 讲道理我本机测试了一下 Go 的 gin 也就 300 qps。 配置是 i3 8g。可能是我打开的方式不对。。
|
72
YMB 2018-01-05 16:33:26 +08:00
@Tairy 刚刚搜了下,http://ifeve.com/talk-arch-module/ 貌似这文章作者也是阿里那边的。
就是系统解耦,按模块分割,每个模块可以高度扩展,扩展力很强,每个模块间以一种私有协议通讯,每个模块可以再无限分布式 |
73
jswh 2018-01-05 16:47:35 +08:00
xhprof 需要配合他自带的那个分析工具看。里面会显示出来每个函数的调用次数和总时间分配,一层层看下去就知道哪里慢了
|
74
puritania 2018-01-05 17:35:01 +08:00
Larvael 慢没得洗,在微服务这么流行的现在,框架带来的作用越来越小了。
|
75
zhujiulin 2018-01-05 19:28:58 +08:00
你确定是 laravel 的锅? 一般 php 很少出问题,mysql io 网络依赖会导致 php 进程一直挂着释放不了
|
76
0x8C 2018-01-05 19:29:36 +08:00
换 php7.2.1 试试,可能是 7.2.0 的 opcache 类型推论引起的性能问题
|
77
Fishdrowned 2018-01-05 22:38:29 +08:00
@wekw 这个框架就是在生产环境中一步步提炼出来的,最后才开源,虽然没什么人用,请你不要张口就就喷没价值。
|
79
abccccabc 2018-01-09 09:26:29 +08:00
|
80
sagaxu 2018-01-09 13:43:38 +08:00
ab 测的是等价的逻辑吗? Document Length 分别是 14B, 10B, 103B
Laravel 的 session 之类的重开销的 Middleware 都禁用了吗? 另外,Laravel 中路由有多少个? 我用 lumen + php 7.1 测过,Laravel 的 echo time(); 在 i5 的机器上,2 个路由的时候,QPS 能跑 5000 左右。 路由数量 100 的时候,QPS 下降到 4000 左右。 路由数量 1000 的时候,QPS 下降到 1100+。 如果用了 1000 个正则做路由,我相信还会更慢。 当我用 100 路由,再开启 session 的时候,QPS 从 4000 左右跌到了 1500+,腰斩了有没有?随便再引入几条正则路由,再开几个 Middleware,那 QPS 估计就跟楼主那个一样了。 |
81
Tairy OP |
82
sagaxu 2018-01-11 13:37:22 +08:00
@Tairy 加上 seession 和那些 middleware 之后,别的 FPM 下跑的框架也不会快太多。你现在有两个比较合适的选择,一是用 Swoole 适配 Laravel,二是把部分瓶颈 API 重构成 Go 语言。第一个方案已经有不少人做过了,可以找得到例子。第二个方案是最近一两年很多公司的选择。100 个 API 里,访问量高的,可能也就不到 20 个。
|
84
wekw 2018-01-12 10:36:24 +08:00
@abccccabc 这个框架毫无扩展性,底层设计不合理导致需要用 PHP 做很多扩展,最后自然就变差了。我们要坚定 Laravel 不动摇,这货绝不只是开发效率高,其架构对大型系统也是非常合理的。
|
85
sxdubin 2018-01-12 11:11:17 +08:00
打印一个"Hello world",Laravel 需要初始化 30 多个实例,主要的消耗在于磁盘 IO,导致 CPU 使用率升高,建议尝试下 Laravel 和 Swoole 的结合,在代码全部加载到内存中,我们这边最近也在使用这个,效率提升 10 倍没有问题的。
|
86
kylesean 2018-01-19 22:25:59 +08:00
SQL 优化了吗?
|
87
imbo 2018-12-14 14:24:43 +08:00
laravel 确实慢,laravel 用了许多反射,影响性能,数据库比较吃内存,建议换框架吧,老铁,推荐 slim 框架
|
88
imbo 2018-12-14 14:29:58 +08:00
|
89
Tairy OP 最近更新了一下,欢迎拍砖
|
90
NtosKiking 2019-05-14 13:33:35 +08:00
学到了
|