上半年把公司的项目用 Laravel 重构了一把，下半年流量大了之后线上 CPU 狂报警，网上都说 Laravel 慢的不行，求问有经验的大神，Larvael 到底能慢到什么程度，心里好有点谱。
感觉又要重构了，😭😭😭！
This topic created in 3225 days ago, the information mentioned may be changed or developed.
Supplement 1 · Jan 4, 2018
总结一下大家的回答：
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 上了，发现确实看不懂，求大神指教。
======
求大神指教迁移方案，不胜感激。
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 上了，发现确实看不懂，求大神指教。
======
求大神指教迁移方案，不胜感激。
Supplement 2 · Jan 4, 2018
UPDATE:
刚才找了一台机器压测了一下，就一个 echo time();
原生php
TP
Laravel
哎，不说了，滚去老老实实重构了。
程序员就不应该只图自己一时爽啊。
Supplement 3 · May 9, 2019
两年了，看到还有人收藏，回来补充一下，结论就是，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 的占用等信息，便可知道慢在哪里了。
 |
mchlJan 4, 2018 via iPhone
1
搜 laravel opcache
|
 |
kslrJan 4, 2018
3
最近关于 PHP 的帖子都是招黑啊
|
|
kslrJan 4, 2018
4
CPU 报警找到原因了吗？
|
 |
akiraJan 4, 2018
5
先确认是什么地方出现瓶颈吧。
|
 |
flyingghostJan 4, 2018
7
@akira 请教如何找瓶颈？
|
 |
assadJan 4, 2018 via Android
9
这个框架性能上确实堪忧
|
|
kslrJan 4, 2018
11
真的是招黑啊，只懂得使用，其他什么都不知道，不知道该如何讲起。建议你先做好系统监控吧，打好日志。
解释的话真的是一点意思也没有了。 |
 |
guoerJan 4, 2018 via iPhone
12
xphrof
|
 |
gcloveJan 4, 2018
13
慢是相对来说的， 说不慢的都是再讲 违心的慌
建议开启 opcache 然后， 缓存自动加载 composer install --optimize-autoloader 缓存配置(当然你要修改配置, 必须清除缓存) php artisan config:cache 缓存路由 php artisan route:cache ==== 然后你看看你不是有过多的数据库查询 ? 能不能加索引， 或者 脱离数据库 使用缓存， 消息队列 解决 |
 |
terranboyJan 4, 2018
14
流量大了 压力根本就不应该在 PHP 上面吧 NGINX 和 Redis 等才是承载压力的主力 如果是 那就是架构问题了
|
|
gcloveJan 4, 2018
15
其次是看, PHP 版本, 系统版本, 服务器性能，磁盘性能，网络健康状况 这些
我用 Laravel 做过 100w pv 的项目。 当然，你要看流量峰值的 |
 |
desJan 4, 2018 via Android
16
优化了之后没有明显改善？
感觉不是框架的问题。 如#12 楼所说，上 xphrof |
 |
lianyueJan 4, 2018
17
php 慢 做集群 😂
|
 |
qiayueJan 4, 2018
19
数据库加索引没有？
|
 |
znJan 4, 2018
22
哈哈，重构换用 symfony 4 吧骚年，全宇宙最快的重量级 PHP 框架之一哦。
|
 |
tomczhenJan 4, 2018
23
毫无营养的问题，换成任意一种框架和语言都行。
架构，业务规模，初步性能分析，监控数据、日志，就这些都没有，难道靠“感觉”优化吗？ |
 |
TangMonkJan 4, 2018 via Android
26
每秒 3000 已经很不错了好吧，还嫌不够就集群啊
|
 |
29
@TangMonk 数据库层倒是没多大问题，因为我们搜索业务比较重，所以大量的查询都走到搜索引擎，这块用的是阿里云的 OpenSearch，猜想可能是瓶颈之一。
|
|
TangMonkJan 4, 2018 via Android
30
@Tairy 你给服务器装个 APM 监控一下性能试试，用国外的 newrelic 或者国内的 OneAPM，可以看到很详细的性能数据
|
 |
nicevarJan 4, 2018
31
刚给公司解决了瓶颈问题，重点还是数据库查询这一块，榨干每一个地方，用重型框架就是这样，业务没上来的时候看似没什么问题，一旦上来了问题就凸显出来了，加上有些同事写代码的时候不考虑性能，为了省事用现成的查询封装就为了取一两个字段而不去重新写查询逻辑，非常浪费资源
|
 |
l57t7qJan 4, 2018 via Android
33
我这里 api 日访问量大概有 800w，单机无压力
|
 |
ghostsfJan 4, 2018 via Android
35
既然集群，索引，缓存都搞了，那么主要就是要 review 代码，优化数据库操作了。检查下代码里，哪里处理数据，查询数据库很慢，然后拿出来分析优化下。
|
 |
defunct9Jan 4, 2018 via iPhone
36
开 ssh，上去看看👀
|
 |
deepkolosJan 4, 2018
37
xdebug 有可以找性能瓶颈
|
 |
MeteorCatJan 4, 2018 via Android
38
这框架就这样，排查下是不是数据库问题，select 是不是没用的都给*查询出来，还有看下第三方是不是加载过多了，这框架量小没啥问题，量大的时候分分种让你哭死
|
 |
FishdrownedJan 4, 2018
39
让我告诉你 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 |
 |
dryyunJan 4, 2018
40
所以，换个框架吧。
|
 |
XrongJan 4, 2018
41
看看卡在哪个 SQL 上吧
|
|
FishdrownedJan 4, 2018
42
Laravel 慢不是什么地方出瓶颈了，而是 Laravel 这个框架本身就是瓶颈。
优化点： 1. 重构 router，特别是你的路由比较多的时候，foreach 之后还要正则就是找不痛快； 2. 用 swoole 服务模式把需要重复初始化的地方抹平，只初始化一次，不过这个会进入普通 php 程序员不熟悉的领域，而且大部分业务逻辑以及第三方组件需要修改以适应服务模式； 3. 放弃 Laravel |
|
guoerJan 4, 2018 via iPhone
43
单台 3k 吗？ 先多开几台 php 机器看看。
xhprof 有工具可以生成图的，多搜索下。 这是个成长的好机会。好好把握 |
 |
lifeintoolsJan 4, 2018
44
羡慕这种机会。。
|
 |
VeigarJan 4, 2018
45
Go 最慢的 beego + redis 2 核 2G 垃圾云 单台 7k
|
 |
darlucJan 4, 2018
46
@Fishdrowned 这个想法不错 swoole + phalcon
|
 |
dawniiiJan 4, 2018
47
|
|
dawniiiJan 4, 2018
48
 |
 |
cha1Jan 4, 2018
49
|
 |
cjyang1128Jan 4, 2018
50
先看懂 xhprof 再说吧。。
|
 |
duskxJan 5, 2018
51
话说真没感觉到慢
|
 |
lalala121Jan 5, 2018
52
symfony 在向你招手
|
 |
TypeErrorNoneJan 5, 2018
53
你机器的配置是什么？
|
 |
freeminderJan 5, 2018
55
之前的项目是 yaf 的路由+laravel 的 orm，离线部分利用了 laravel 的 schedule 和 artisan，之后看性能 laravel 主要在 ORM 的部分了，序列化真的要调用好多层
|
 |
scofieldpengJan 5, 2018
56
话说前几天我司外包组的接了一个维护投票的活，上家坑爹给人家在千万云上买了 8 核 16g 内存，这就算了，带宽直接撸了 200 兆，php 写的太差，几千就把 php 进程干掉了，nginx 加缓存，php 跑了多个进程，依然扛不过刷票的那帮土匪，然后，我用 golang 把核心重撸了一个，从此天下太平，所以楼主，要不换下语言？ 2333
|
 |
jhdxrJan 5, 2018
57
laravel 性能的确不是那么好，毕竟遍地匿名函数，但测也不是你这么测的，laravel 是一个默认开启 session 的框架，而其他框架或者原生你压测是没有的，这个不用说在网上，在 V2EX 上也已经有无数人测过然后被指正过了
然后你这个帖子通篇没有任何信息量。CPU 狂报警，那什么程序在那吃 CPU 你看了吗？如果看下来是 MySQL 占用高，那多半是 SQL 没写好（哪怕用了 ORM，最终也会生成 SQL ）；如果是 PHP-FPM，那的确就是得优化 PHP 代码了（然而你并看不懂 xhprof _(:з」∠)_） 总觉得 PHP 日常被黑，面向 google 编程你早晚遇到瓶颈，只是来的或早或晚而已。 |
 |
wekwJan 5, 2018
58
CPU 报警真是奇怪。。。。一般都是数据库优化不到位，内存爆炸，响应时间大幅增加。
|
 |
kkeikoJan 5, 2018
60
laravel 本身是不错的框架，和其他框架比，慢也是事实，但同时开发更优雅，解耦更强也是事实。根本上还是要看使用者要的是什么，但有一点可以肯定的是，从来没有万能的框架，laravel 也是如此，技术架构是要不断迭代更新来适应业务的。而不能说 laravel 在这个时间节点不适应你的业务就是不好的。
|
 |
keikeizhangJan 5, 2018
62
Yaf 你最佳的选择
或者直接 JAVA 我们公司用 Lumen 开发 API |
 |
kimmykuangJan 5, 2018
63
不要用 fpm 模式啊
|
 |
st2udioJan 5, 2018
64
我上次开了 800 个 fpm 进程，跑 laravel
|
 |
YMBJan 5, 2018
65
你们没管架构的吗。。。组长。。总监之类的。。。
模块化啊。。模块间 API 通讯。。无敌的。。 阿里有些架构就这么干的。。 |
 |
sampengJan 5, 2018
68
加机器啊。。。。。能用机器解决的问题。干嘛用人来解决。程序员一年工资 10-30 万。一台机器一年才多少钱。。。
|
|
wekwJan 5, 2018
70
@Fishdrowned 老实说你的回复是这么多回复中最没价值的，因为一看你就没用你所说的这个架构做过任何一个生产环境的项目。用过 phalcon 的人都会吐血的。
|
|
YMBJan 5, 2018
72
@Tairy 刚刚搜了下，http://ifeve.com/talk-arch-module/ 貌似这文章作者也是阿里那边的。
就是系统解耦，按模块分割，每个模块可以高度扩展，扩展力很强，每个模块间以一种私有协议通讯，每个模块可以再无限分布式 |
 |
jswhJan 5, 2018
73
xhprof 需要配合他自带的那个分析工具看。里面会显示出来每个函数的调用次数和总时间分配，一层层看下去就知道哪里慢了
|
 |
puritaniaJan 5, 2018
74
Larvael 慢没得洗，在微服务这么流行的现在，框架带来的作用越来越小了。
|
 |
zhujiulinJan 5, 2018
75
你确定是 laravel 的锅？ 一般 php 很少出问题，mysql io 网络依赖会导致 php 进程一直挂着释放不了
|
 |
0x8CJan 5, 2018
76
换 php7.2.1 试试，可能是 7.2.0 的 opcache 类型推论引起的性能问题
|
|
FishdrownedJan 5, 2018
77
@wekw 这个框架就是在生产环境中一步步提炼出来的，最后才开源，虽然没什么人用，请你不要张口就就喷没价值。
|
 |
abccccabcJan 9, 2018
79
|
 |
sagaxuJan 9, 2018
80
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 估计就跟楼主那个一样了。 |
|
sagaxuJan 11, 2018
82
@Tairy 加上 seession 和那些 middleware 之后，别的 FPM 下跑的框架也不会快太多。你现在有两个比较合适的选择，一是用 Swoole 适配 Laravel，二是把部分瓶颈 API 重构成 Go 语言。第一个方案已经有不少人做过了，可以找得到例子。第二个方案是最近一两年很多公司的选择。100 个 API 里，访问量高的，可能也就不到 20 个。
|
|
wekwJan 12, 2018
84
@abccccabc 这个框架毫无扩展性，底层设计不合理导致需要用 PHP 做很多扩展，最后自然就变差了。我们要坚定 Laravel 不动摇，这货绝不只是开发效率高，其架构对大型系统也是非常合理的。
|
 |
sxdubinJan 12, 2018
85
打印一个"Hello world"，Laravel 需要初始化 30 多个实例，主要的消耗在于磁盘 IO，导致 CPU 使用率升高，建议尝试下 Laravel 和 Swoole 的结合，在代码全部加载到内存中，我们这边最近也在使用这个，效率提升 10 倍没有问题的。
|
 |
kyleseanJan 19, 2018
86
SQL 优化了吗？
|
 |
imboDec 14, 2018
87
laravel 确实慢，laravel 用了许多反射，影响性能，数据库比较吃内存，建议换框架吧，老铁，推荐 slim 框架
|
|
imboDec 14, 2018
88
|
|
89
最近更新了一下，欢迎拍砖
|
 |
NtosKikingMay 14, 2019
90
学到了
|
Select Language