Laravel 到底能慢到什么程度？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2548 天前的主题，其中的信息可能已经有所发展或是发生改变。

上半年把公司的项目用 Laravel 重构了一把，下半年流量大了之后线上 CPU 狂报警，网上都说 Laravel 慢的不行，求问有经验的大神，Larvael 到底能慢到什么程度，心里好有点谱。

感觉又要重构了，😭😭😭！

第 1 条附言 · 2018-01-04 20:31:46 +08:00

总结一下大家的回答：

1. php 7.2
2. opcache 开了
3.

```
composer install --optimize-autoloader
php artisan config:cache
php artisan route:cache
```
都执行过了。
4. 现在高峰期 QPS 3000 左右。
5. 加了 Redis 缓存。
6. 数据库索引加了。
7. xphrof 上了，发现确实看不懂，求大神指教。

======

求大神指教迁移方案，不胜感激。

第 2 条附言 · 2018-01-04 21:52:56 +08:00

UPDATE:

刚才找了一台机器压测了一下，就一个 echo time();

原生php

Laravel

哎，不说了，滚去老老实实重构了。

程序员就不应该只图自己一时爽啊。

第 3 条附言 · 2019-05-09 19:13:15 +08:00

两年了，看到还有人收藏，回来补充一下，结论就是，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 的占用等信息，便可知道慢在哪里了。

laravel

重构

larvael

CPU

91 条回复 • 2021-08-25 16:54:07 +08:00

mchl

2018-01-04 19:44:34 +08:00 via iPhone

搜 laravel opcache

Tairy

2018-01-04 19:45:42 +08:00

@mchl 这些早都加上了，网上能搜到的优化方案都用上了

kslr

2018-01-04 19:45:59 +08:00

最近关于 PHP 的帖子都是招黑啊

kslr

2018-01-04 19:46:29 +08:00

CPU 报警找到原因了吗？

akira

2018-01-04 19:48:18 +08:00

先确认是什么地方出现瓶颈吧。

Tairy

2018-01-04 19:49:58 +08:00

@kslr 还没查到确切的原因，用 ab 测试了一下 laravel 和别的框架，输出同样的内容 laravel 的表现堪忧啊。

flyingghost

2018-01-04 19:50:53 +08:00

@akira 请教如何找瓶颈？

Tairy

2018-01-04 19:51:27 +08:00

@akira 能想到是瓶颈的地方都试过了，发现改了之后也没啥明显优化，现在唯一能想到的就是可能 Laravel 的性能真的不行。

assad

2018-01-04 19:52:06 +08:00 via Android

这个框架性能上确实堪忧

Tairy

2018-01-04 19:52:42 +08:00

@assad 大佬有实际使用经验么，达到什么量级就扛不住了啊。

kslr

2018-01-04 19:55:23 +08:00

真的是招黑啊，只懂得使用，其他什么都不知道，不知道该如何讲起。建议你先做好系统监控吧，打好日志。
解释的话真的是一点意思也没有了。

guoer

2018-01-04 20:00:40 +08:00 via iPhone

xphrof

gclove

2018-01-04 20:05:31 +08:00

慢是相对来说的，说不慢的都是再讲违心的慌

建议开启 opcache

然后，缓存自动加载
composer install --optimize-autoloader

缓存配置(当然你要修改配置, 必须清除缓存)
php artisan config:cache

缓存路由
php artisan route:cache

====

然后你看看你不是有过多的数据库查询 ?

能不能加索引，或者脱离数据库使用缓存，消息队列解决

terranboy

2018-01-04 20:06:05 +08:00

流量大了压力根本就不应该在 PHP 上面吧 NGINX 和 Redis 等才是承载压力的主力如果是那就是架构问题了

gclove

2018-01-04 20:09:09 +08:00

其次是看, PHP 版本, 系统版本, 服务器性能，磁盘性能，网络健康状况这些

我用 Laravel 做过 100w pv 的项目。当然，你要看流量峰值的

des

2018-01-04 20:21:18 +08:00 via Android

优化了之后没有明显改善？
感觉不是框架的问题。
如#12 楼所说，上 xphrof

lianyue

2018-01-04 20:24:25 +08:00

php 慢做集群 😂

Tairy

2018-01-04 20:25:41 +08:00

@gclove 这些都做过了。
@des xphrof 之后输出一大堆，没办法看，求问有没有看这个的经验。

qiayue

2018-01-04 20:25:41 +08:00

数据库加索引没有？

Tairy

2018-01-04 20:26:10 +08:00

@qiayue 这个肯定加了，能缓存的基本上都缓存到 redis 里面了。

gclove

2018-01-04 20:28:46 +08:00

@Tairy 感觉要达到你描述的效果，至少要很多的请求流量啊。

所以什么业务和流量的状况能说一下吗

2018-01-04 20:30:06 +08:00

哈哈，重构换用 symfony 4 吧骚年，全宇宙最快的重量级 PHP 框架之一哦。

tomczhen

2018-01-04 20:32:47 +08:00

毫无营养的问题，换成任意一种框架和语言都行。

架构，业务规模，初步性能分析，监控数据、日志，就这些都没有，难道靠“感觉”优化吗？

Tairy

2018-01-04 20:34:24 +08:00

@tomczhen 提问的时候没写太多，只是想找找看有没有相关经验的朋友，之后回跟进相关的信息的。

des

2018-01-04 20:36:52 +08:00 via Android

@Tairy 你搜索一下，网上介绍这个的文章多如牛毛，虽然都是相互抄的

TangMonk

2018-01-04 20:39:10 +08:00 via Android

每秒 3000 已经很不错了好吧，还嫌不够就集群啊

Tairy

2018-01-04 20:41:16 +08:00

@TangMonk 现在跑 13 台机器，有 8 核 8 G，8 核 16G 和 16 核 16 G 三种配置。

TangMonk

2018-01-04 20:43:53 +08:00 via Android

@Tairy 13 台机器确实有点慢了，是不是有数据库锁或者其他阻塞操作？

Tairy

2018-01-04 20:45:53 +08:00

@TangMonk 数据库层倒是没多大问题，因为我们搜索业务比较重，所以大量的查询都走到搜索引擎，这块用的是阿里云的 OpenSearch，猜想可能是瓶颈之一。

TangMonk

2018-01-04 20:47:54 +08:00 via Android

@Tairy 你给服务器装个 APM 监控一下性能试试，用国外的 newrelic 或者国内的 OneAPM，可以看到很详细的性能数据

nicevar

2018-01-04 20:49:17 +08:00

刚给公司解决了瓶颈问题，重点还是数据库查询这一块，榨干每一个地方，用重型框架就是这样，业务没上来的时候看似没什么问题，一旦上来了问题就凸显出来了，加上有些同事写代码的时候不考虑性能，为了省事用现成的查询封装就为了取一两个字段而不去重新写查询逻辑，非常浪费资源

TangMonk

2018-01-04 20:50:22 +08:00 via Android

@zn symfony4 还有些必要的 bundle 没有升级过来

l57t7q

2018-01-04 20:57:51 +08:00 via Android

我这里 api 日访问量大概有 800w，单机无压力

Tairy

2018-01-04 21:00:40 +08:00

@l57t7q 单机啥配置啊大哥。

ghostsf

2018-01-04 21:03:05 +08:00 via Android

既然集群，索引，缓存都搞了，那么主要就是要 review 代码，优化数据库操作了。检查下代码里，哪里处理数据，查询数据库很慢，然后拿出来分析优化下。

defunct9

2018-01-04 21:04:14 +08:00 via iPhone

开 ssh，上去看看👀

deepkolos

2018-01-04 21:05:17 +08:00

xdebug 有可以找性能瓶颈

MeteorCat

2018-01-04 21:16:17 +08:00 via Android

这框架就这样，排查下是不是数据库问题，select 是不是没用的都给*查询出来，还有看下第三方是不是加载过多了，这框架量小没啥问题，量大的时候分分种让你哭死

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

dryyun

2018-01-04 21:20:01 +08:00

所以，换个框架吧。

Xrong

2018-01-04 21:22:26 +08:00

看看卡在哪个 SQL 上吧

Fishdrowned

2018-01-04 21:23:19 +08:00

Laravel 慢不是什么地方出瓶颈了，而是 Laravel 这个框架本身就是瓶颈。
优化点：
1. 重构 router，特别是你的路由比较多的时候，foreach 之后还要正则就是找不痛快；
2. 用 swoole 服务模式把需要重复初始化的地方抹平，只初始化一次，不过这个会进入普通 php 程序员不熟悉的领域，而且大部分业务逻辑以及第三方组件需要修改以适应服务模式；
3. 放弃 Laravel

guoer

2018-01-04 21:23:27 +08:00 via iPhone

单台 3k 吗？先多开几台 php 机器看看。
xhprof 有工具可以生成图的，多搜索下。
这是个成长的好机会。好好把握

lifeintools

2018-01-04 21:39:16 +08:00

羡慕这种机会。。

Veigar

2018-01-04 22:05:00 +08:00

Go 最慢的 beego + redis 2 核 2G 垃圾云单台 7k

darluc

2018-01-04 22:44:15 +08:00

@Fishdrowned 这个想法不错 swoole + phalcon

dawniii

2018-01-04 22:48:40 +08:00

https://i.loli.net/2018/01/04/5a4e3e65e5a87.jpg

上面都在说什么哈哈

dawniii

2018-01-04 22:57:21 +08:00

zqhong

2018-01-04 23:35:52 +08:00

#42 同意 Fishdrowned 的优化建议，Laravel + swoole。

可参考： https://github.com/huang-yi/laravel-swoole-http

cjyang1128

2018-01-04 23:52:35 +08:00

先看懂 xhprof 再说吧。。

957204459

2018-01-05 09:16:23 +08:00

话说真没感觉到慢

lalala121

2018-01-05 09:17:31 +08:00

symfony 在向你招手

TypeErrorNone

2018-01-05 09:38:52 +08:00

你机器的配置是什么？

wwek

2018-01-05 09:57:01 +08:00

@dawniii 鸟哥语录没毛病

freeminder

2018-01-05 09:59:24 +08:00

之前的项目是 yaf 的路由+laravel 的 orm，离线部分利用了 laravel 的 schedule 和 artisan，之后看性能 laravel 主要在 ORM 的部分了，序列化真的要调用好多层

scofieldpeng

2018-01-05 10:20:02 +08:00

话说前几天我司外包组的接了一个维护投票的活，上家坑爹给人家在千万云上买了 8 核 16g 内存，这就算了，带宽直接撸了 200 兆，php 写的太差，几千就把 php 进程干掉了，nginx 加缓存，php 跑了多个进程，依然扛不过刷票的那帮土匪，然后，我用 golang 把核心重撸了一个，从此天下太平，所以楼主，要不换下语言？ 2333

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 编程你早晚遇到瓶颈，只是来的或早或晚而已。

wekw

2018-01-05 10:20:20 +08:00

CPU 报警真是奇怪。。。。一般都是数据库优化不到位，内存爆炸，响应时间大幅增加。

Tairy

2018-01-05 10:26:16 +08:00

@jhdxr 真的不是黑 PHP，就是提出个疑问而已，我已经在抓 xhprof 研究了，占用 CPU 的就是 fpm，MySQL 是独立的主机。

kkeiko

2018-01-05 10:31:54 +08:00

laravel 本身是不错的框架，和其他框架比，慢也是事实，但同时开发更优雅，解耦更强也是事实。根本上还是要看使用者要的是什么，但有一点可以肯定的是，从来没有万能的框架，laravel 也是如此，技术架构是要不断迭代更新来适应业务的。而不能说 laravel 在这个时间节点不适应你的业务就是不好的。

kkeiko

2018-01-05 10:34:47 +08:00

@kkeiko 顺便给个建议，如果是小项目，维护的人不多，放弃 laravel 吧，得不偿失。yaf 是最好的选择。

keikeizhang

2018-01-05 10:37:19 +08:00

Yaf 你最佳的选择

或者直接 JAVA

我们公司用 Lumen 开发 API

kimmykuang

2018-01-05 11:03:49 +08:00

不要用 fpm 模式啊

st2udio

2018-01-05 11:24:22 +08:00

我上次开了 800 个 fpm 进程，跑 laravel

YMB

2018-01-05 11:33:55 +08:00

你们没管架构的吗。。。组长。。总监之类的。。。
模块化啊。。模块间 API 通讯。。无敌的。。
阿里有些架构就这么干的。。

Tairy

2018-01-05 11:45:04 +08:00

@st2udio 我们之前 1200 发现 cpu 很容易爆，就改到 800, 基本上最合适了吧。

Tairy

2018-01-05 11:45:32 +08:00

@YMB 小公司哪有这些。

sampeng

2018-01-05 13:42:11 +08:00

加机器啊。。。。。能用机器解决的问题。干嘛用人来解决。程序员一年工资 10-30 万。一台机器一年才多少钱。。。

HYSS

2018-01-05 14:53:04 +08:00

@Veigar 你没算数据库吧

wekw

2018-01-05 15:19:28 +08:00

@Fishdrowned 老实说你的回复是这么多回复中最没价值的，因为一看你就没用你所说的这个架构做过任何一个生产环境的项目。用过 phalcon 的人都会吐血的。

zzWinD

2018-01-05 16:17:07 +08:00

@Veigar 讲道理我本机测试了一下 Go 的 gin 也就 300 qps。配置是 i3 8g。可能是我打开的方式不对。。

YMB

2018-01-05 16:33:26 +08:00

@Tairy 刚刚搜了下，http://ifeve.com/talk-arch-module/ 貌似这文章作者也是阿里那边的。
就是系统解耦，按模块分割，每个模块可以高度扩展，扩展力很强，每个模块间以一种私有协议通讯，每个模块可以再无限分布式

jswh

2018-01-05 16:47:35 +08:00

xhprof 需要配合他自带的那个分析工具看。里面会显示出来每个函数的调用次数和总时间分配，一层层看下去就知道哪里慢了

puritania

2018-01-05 17:35:01 +08:00

Larvael 慢没得洗，在微服务这么流行的现在，框架带来的作用越来越小了。

zhujiulin

2018-01-05 19:28:58 +08:00

你确定是 laravel 的锅？一般 php 很少出问题，mysql io 网络依赖会导致 php 进程一直挂着释放不了

0x8C

2018-01-05 19:29:36 +08:00

换 php7.2.1 试试，可能是 7.2.0 的 opcache 类型推论引起的性能问题

Fishdrowned

2018-01-05 22:38:29 +08:00

@wekw 这个框架就是在生产环境中一步步提炼出来的，最后才开源，虽然没什么人用，请你不要张口就就喷没价值。

Veigar

2018-01-06 00:40:10 +08:00

@HYSS 用的 redis 当数据库

abccccabc

2018-01-09 09:26:29 +08:00

@wekw 你好，在用 phalcon 框架中，你觉得整体速度不会太快，会是出在哪个地方呢？ Yaf 的功能过于简单，要 composer 数据库类、助手类、其它要用到的类，好累呀。

@Tairy 你有查过 php 慢日志没？既然出现了性能问题，这个是要重点分析的。

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 估计就跟楼主那个一样了。

Tairy

2018-01-10 09:50:55 +08:00

@sagaxu
1. session 有些功能有用到，所以没有关。
2. 路由确实 100 多。
3. middleware 也有用到。

sagaxu

2018-01-11 13:37:22 +08:00

@Tairy 加上 seession 和那些 middleware 之后，别的 FPM 下跑的框架也不会快太多。你现在有两个比较合适的选择，一是用 Swoole 适配 Laravel，二是把部分瓶颈 API 重构成 Go 语言。第一个方案已经有不少人做过了，可以找得到例子。第二个方案是最近一两年很多公司的选择。100 个 API 里，访问量高的，可能也就不到 20 个。

Tairy

2018-01-12 09:35:21 +08:00

@sagaxu 嗯我正在用 yaf 把访问量高的 API 做重构。

wekw

2018-01-12 10:36:24 +08:00

@abccccabc 这个框架毫无扩展性，底层设计不合理导致需要用 PHP 做很多扩展，最后自然就变差了。我们要坚定 Laravel 不动摇，这货绝不只是开发效率高，其架构对大型系统也是非常合理的。