V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Tairy
V2EX  ›  PHP

Laravel 到底能慢到什么程度?

  •  2
     
  •   Tairy · 2018-01-04 19:25:46 +08:00 · 28757 次点击
    这是一个创建于 2516 天前的主题,其中的信息可能已经有所发展或是发生改变。

    上半年把公司的项目用 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

    TP

    Laravel

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

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

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

    两年了,看到还有人收藏,回来补充一下,结论就是,laravel 确实很慢,高流量业务千万别用,我们的业务已经基本都迁移了,期间遇到的坑在这里写一下:

    1. 路由,众所周知,Laravel 的路由组件是出了名的慢,主要是用反射之类的东西(具体原理记不清了,总之就是很慢)。

    2. Eloquent,虽然提供了很方便的数据库操作接口,但是每次 new model 的时候,如果有 fillable 的属性,他会把所以的字段都给你填充一边,这样在循环中,或者大流量下,瞬间对系统资源的占用是很大的。

    3. Guzzle http client,实际测试过使用这个 client 发起多次 http 请求,几乎所有的对象都不会复用(猜测),所以导致期间进行的内存分配和 new 对象的次数,比随手用 curl 写一个 client 要多上万倍。

    总结来讲就是 Laravel 在对象的创建和内存的复用方面,是很奢侈的,而且一个请求下来,会经历无数的没什么用的操作,对于资源是一点也不节省。

    以上,基于之前提问是 5.6.5 版本,这两年来我们团队填坑发现到的一些问题,最新版本的再没有研究过,总之就是用 PHP 写东西还是按需获取资源,能少调用一次函数就少调用一次,能少 new 一个对象就少 new 一个,浪费可耻,也慢。

    最后,这些都属于回忆的时候写的,有些细节可能不尽准确,大概方向就是这些。

    具体查问题的办法就是使用性能采集扩展,目前支持 php 7 的有 php-xhprof-extension , 也可以参考这个扩展自研,满足自己的采集需求,查看自己的代码在执行过程中对内存的申请、CPU 的占用等信息,便可知道慢在哪里了。

    91 条回复    2021-08-25 16:54:07 +08:00
    mchl
        1
    mchl  
       2018-01-04 19:44:34 +08:00 via iPhone
    搜 laravel opcache
    Tairy
        2
    Tairy  
    OP
       2018-01-04 19:45:42 +08:00
    @mchl 这些早都加上了,网上能搜到的优化方案都用上了
    kslr
        3
    kslr  
       2018-01-04 19:45:59 +08:00
    最近关于 PHP 的帖子都是招黑啊
    kslr
        4
    kslr  
       2018-01-04 19:46:29 +08:00
    CPU 报警找到原因了吗?
    akira
        5
    akira  
       2018-01-04 19:48:18 +08:00
    先确认是什么地方出现瓶颈吧。
    Tairy
        6
    Tairy  
    OP
       2018-01-04 19:49:58 +08:00
    @kslr 还没查到确切的原因,用 ab 测试了一下 laravel 和别的框架,输出同样的内容 laravel 的表现堪忧啊。
    flyingghost
        7
    flyingghost  
       2018-01-04 19:50:53 +08:00
    @akira 请教如何找瓶颈?
    Tairy
        8
    Tairy  
    OP
       2018-01-04 19:51:27 +08:00
    @akira 能想到是瓶颈的地方都试过了,发现改了之后也没啥明显优化,现在唯一能想到的就是可能 Laravel 的性能真的不行。
    assad
        9
    assad  
       2018-01-04 19:52:06 +08:00 via Android
    这个框架性能上确实堪忧
    Tairy
        10
    Tairy  
    OP
       2018-01-04 19:52:42 +08:00
    @assad 大佬有实际使用经验么,达到什么量级就扛不住了啊。
    kslr
        11
    kslr  
       2018-01-04 19:55:23 +08:00
    真的是招黑啊,只懂得使用,其他什么都不知道,不知道该如何讲起。建议你先做好系统监控吧,打好日志。
    解释的话真的是一点意思也没有了。
    guoer
        12
    guoer  
       2018-01-04 20:00:40 +08:00 via iPhone
    xphrof
    gclove
        13
    gclove  
       2018-01-04 20:05:31 +08:00
    慢是相对来说的, 说不慢的都是再讲 违心的慌

    建议开启 opcache


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

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

    缓存路由
    php artisan route:cache

    ====

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

    能不能加索引, 或者 脱离数据库 使用缓存, 消息队列 解决
    terranboy
        14
    terranboy  
       2018-01-04 20:06:05 +08:00
    流量大了 压力根本就不应该在 PHP 上面吧 NGINX 和 Redis 等才是承载压力的主力 如果是 那就是架构问题了
    gclove
        15
    gclove  
       2018-01-04 20:09:09 +08:00
    其次是看, PHP 版本, 系统版本, 服务器性能,磁盘性能,网络健康状况 这些

    我用 Laravel 做过 100w pv 的项目。 当然,你要看流量峰值的
    des
        16
    des  
       2018-01-04 20:21:18 +08:00 via Android
    优化了之后没有明显改善?
    感觉不是框架的问题。
    如#12 楼所说,上 xphrof
    lianyue
        17
    lianyue  
       2018-01-04 20:24:25 +08:00
    php 慢 做集群 😂
    Tairy
        18
    Tairy  
    OP
       2018-01-04 20:25:41 +08:00
    @gclove 这些都做过了。
    @des xphrof 之后输出一大堆,没办法看,求问有没有看这个的经验。
    qiayue
        19
    qiayue  
       2018-01-04 20:25:41 +08:00
    数据库加索引没有?
    Tairy
        20
    Tairy  
    OP
       2018-01-04 20:26:10 +08:00
    @qiayue 这个肯定加了,能缓存的基本上都缓存到 redis 里面了。
    gclove
        21
    gclove  
       2018-01-04 20:28:46 +08:00
    @Tairy 感觉要达到你描述的效果,至少要很多的请求流量啊。

    所以什么业务 和 流量的状况能说一下吗
    zn
        22
    zn  
       2018-01-04 20:30:06 +08:00
    哈哈,重构换用 symfony 4 吧骚年,全宇宙最快的重量级 PHP 框架之一哦。
    tomczhen
        23
    tomczhen  
       2018-01-04 20:32:47 +08:00
    毫无营养的问题,换成任意一种框架和语言都行。

    架构,业务规模,初步性能分析,监控数据、日志,就这些都没有,难道靠“感觉”优化吗?
    Tairy
        24
    Tairy  
    OP
       2018-01-04 20:34:24 +08:00
    @tomczhen 提问的时候没写太多,只是想找找看有没有相关经验的朋友,之后回跟进相关的信息的。
    des
        25
    des  
       2018-01-04 20:36:52 +08:00 via Android
    @Tairy 你搜索一下,网上介绍这个的文章多如牛毛,虽然都是相互抄的
    TangMonk
        26
    TangMonk  
       2018-01-04 20:39:10 +08:00 via Android
    每秒 3000 已经很不错了好吧,还嫌不够就集群啊
    Tairy
        27
    Tairy  
    OP
       2018-01-04 20:41:16 +08:00
    @TangMonk 现在跑 13 台机器,有 8 核 8 G,8 核 16G 和 16 核 16 G 三种配置。
    TangMonk
        28
    TangMonk  
       2018-01-04 20:43:53 +08:00 via Android
    @Tairy 13 台机器确实有点慢了,是不是有数据库锁或者其他阻塞操作?
    Tairy
        29
    Tairy  
    OP
       2018-01-04 20:45:53 +08:00
    @TangMonk 数据库层倒是没多大问题,因为我们搜索业务比较重,所以大量的查询都走到搜索引擎,这块用的是阿里云的 OpenSearch,猜想可能是瓶颈之一。
    TangMonk
        30
    TangMonk  
       2018-01-04 20:47:54 +08:00 via Android
    @Tairy 你给服务器装个 APM 监控一下性能试试,用国外的 newrelic 或者国内的 OneAPM,可以看到很详细的性能数据
    nicevar
        31
    nicevar  
       2018-01-04 20:49:17 +08:00
    刚给公司解决了瓶颈问题,重点还是数据库查询这一块,榨干每一个地方,用重型框架就是这样,业务没上来的时候看似没什么问题,一旦上来了问题就凸显出来了,加上有些同事写代码的时候不考虑性能,为了省事用现成的查询封装就为了取一两个字段而不去重新写查询逻辑,非常浪费资源
    TangMonk
        32
    TangMonk  
       2018-01-04 20:50:22 +08:00 via Android
    @zn symfony4 还有些必要的 bundle 没有升级过来
    l57t7q
        33
    l57t7q  
       2018-01-04 20:57:51 +08:00 via Android
    我这里 api 日访问量大概有 800w,单机无压力
    Tairy
        34
    Tairy  
    OP
       2018-01-04 21:00:40 +08:00
    @l57t7q 单机啥配置啊大哥。
    ghostsf
        35
    ghostsf  
       2018-01-04 21:03:05 +08:00 via Android
    既然集群,索引,缓存都搞了,那么主要就是要 review 代码,优化数据库操作了。检查下代码里,哪里处理数据,查询数据库很慢,然后拿出来分析优化下。
    defunct9
        36
    defunct9  
       2018-01-04 21:04:14 +08:00 via iPhone
    开 ssh,上去看看👀
    deepkolos
        37
    deepkolos  
       2018-01-04 21:05:17 +08:00
    xdebug 有可以找性能瓶颈
    MeteorCat
        38
    MeteorCat  
       2018-01-04 21:16:17 +08:00 via Android
    这框架就这样,排查下是不是数据库问题,select 是不是没用的都给*查询出来,还有看下第三方是不是加载过多了,这框架量小没啥问题,量大的时候分分种让你哭死
    Fishdrowned
        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
    dryyun
        40
    dryyun  
       2018-01-04 21:20:01 +08:00
    所以,换个框架吧。
    Xrong
        41
    Xrong  
       2018-01-04 21:22:26 +08:00
    看看卡在哪个 SQL 上吧
    Fishdrowned
        42
    Fishdrowned  
       2018-01-04 21:23:19 +08:00
    Laravel 慢不是什么地方出瓶颈了,而是 Laravel 这个框架本身就是瓶颈。
    优化点:
    1. 重构 router,特别是你的路由比较多的时候,foreach 之后还要正则就是找不痛快;
    2. 用 swoole 服务模式把需要重复初始化的地方抹平,只初始化一次,不过这个会进入普通 php 程序员不熟悉的领域,而且大部分业务逻辑以及第三方组件需要修改以适应服务模式;
    3. 放弃 Laravel
    guoer
        43
    guoer  
       2018-01-04 21:23:27 +08:00 via iPhone
    单台 3k 吗? 先多开几台 php 机器看看。
    xhprof 有工具可以生成图的,多搜索下。
    这是个成长的好机会。好好把握
    lifeintools
        44
    lifeintools  
       2018-01-04 21:39:16 +08:00
    羡慕这种机会。。
    Veigar
        45
    Veigar  
       2018-01-04 22:05:00 +08:00
    Go 最慢的 beego + redis 2 核 2G 垃圾云 单台 7k
    darluc
        46
    darluc  
       2018-01-04 22:44:15 +08:00
    @Fishdrowned 这个想法不错 swoole + phalcon
    dawniii
        47
    dawniii  
       2018-01-04 22:48:40 +08:00
    dawniii
        48
    dawniii  
       2018-01-04 22:57:21 +08:00
    zqhong
        49
    zqhong  
       2018-01-04 23:35:52 +08:00
    #42 同意 Fishdrowned 的优化建议,Laravel + swoole。

    可参考: https://github.com/huang-yi/laravel-swoole-http
    cjyang1128
        50
    cjyang1128  
       2018-01-04 23:52:35 +08:00
    先看懂 xhprof 再说吧。。
    957204459
        51
    957204459  
       2018-01-05 09:16:23 +08:00
    话说真没感觉到慢
    lalala121
        52
    lalala121  
       2018-01-05 09:17:31 +08:00
    symfony 在向你招手
    TypeErrorNone
        53
    TypeErrorNone  
       2018-01-05 09:38:52 +08:00
    你机器的配置是什么?
    wwek
        54
    wwek  
       2018-01-05 09:57:01 +08:00
    @dawniii 鸟哥语录没毛病
    freeminder
        55
    freeminder  
       2018-01-05 09:59:24 +08:00
    之前的项目是 yaf 的路由+laravel 的 orm,离线部分利用了 laravel 的 schedule 和 artisan,之后看性能 laravel 主要在 ORM 的部分了,序列化真的要调用好多层
    scofieldpeng
        56
    scofieldpeng  
       2018-01-05 10:20:02 +08:00
    话说前几天我司外包组的接了一个维护投票的活,上家坑爹给人家在千万云上买了 8 核 16g 内存,这就算了,带宽直接撸了 200 兆,php 写的太差,几千就把 php 进程干掉了,nginx 加缓存,php 跑了多个进程,依然扛不过刷票的那帮土匪,然后,我用 golang 把核心重撸了一个,从此天下太平,所以楼主,要不换下语言? 2333
    jhdxr
        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 编程你早晚遇到瓶颈,只是来的或早或晚而已。
    wekw
        58
    wekw  
       2018-01-05 10:20:20 +08:00
    CPU 报警真是奇怪。。。。一般都是数据库优化不到位,内存爆炸,响应时间大幅增加。
    Tairy
        59
    Tairy  
    OP
       2018-01-05 10:26:16 +08:00
    @jhdxr 真的不是黑 PHP,就是提出个疑问而已,我已经在抓 xhprof 研究了,占用 CPU 的就是 fpm,MySQL 是独立的主机。
    kkeiko
        60
    kkeiko  
       2018-01-05 10:31:54 +08:00
    laravel 本身是不错的框架,和其他框架比,慢也是事实,但同时开发更优雅,解耦更强也是事实。根本上还是要看使用者要的是什么,但有一点可以肯定的是,从来没有万能的框架,laravel 也是如此,技术架构是要不断迭代更新来适应业务的。而不能说 laravel 在这个时间节点不适应你的业务就是不好的。
    kkeiko
        61
    kkeiko  
       2018-01-05 10:34:47 +08:00
    @kkeiko 顺便给个建议,如果是小项目,维护的人不多, 放弃 laravel 吧,得不偿失。yaf 是最好的选择。
    keikeizhang
        62
    keikeizhang  
       2018-01-05 10:37:19 +08:00
    Yaf 你最佳的选择

    或者直接 JAVA

    我们公司用 Lumen 开发 API
    kimmykuang
        63
    kimmykuang  
       2018-01-05 11:03:49 +08:00
    不要用 fpm 模式啊
    st2udio
        64
    st2udio  
       2018-01-05 11:24:22 +08:00
    我上次开了 800 个 fpm 进程,跑 laravel
    YMB
        65
    YMB  
       2018-01-05 11:33:55 +08:00
    你们没管架构的吗。。。组长。。总监之类的。。。
    模块化啊。。模块间 API 通讯。。无敌的。。
    阿里有些架构就这么干的。。
    Tairy
        66
    Tairy  
    OP
       2018-01-05 11:45:04 +08:00
    @st2udio 我们之前 1200 发现 cpu 很容易爆,就改到 800, 基本上最合适了吧。
    Tairy
        67
    Tairy  
    OP
       2018-01-05 11:45:32 +08:00
    @YMB 小公司哪有这些。
    sampeng
        68
    sampeng  
       2018-01-05 13:42:11 +08:00
    加机器啊。。。。。能用机器解决的问题。干嘛用人来解决。程序员一年工资 10-30 万。一台机器一年才多少钱。。。
    HYSS
        69
    HYSS  
       2018-01-05 14:53:04 +08:00
    @Veigar 你没算数据库吧
    wekw
        70
    wekw  
       2018-01-05 15:19:28 +08:00
    @Fishdrowned 老实说你的回复是这么多回复中最没价值的,因为一看你就没用你所说的这个架构做过任何一个生产环境的项目。用过 phalcon 的人都会吐血的。
    zzWinD
        71
    zzWinD  
       2018-01-05 16:17:07 +08:00
    @Veigar 讲道理我本机测试了一下 Go 的 gin 也就 300 qps。 配置是 i3 8g。可能是我打开的方式不对。。
    YMB
        72
    YMB  
       2018-01-05 16:33:26 +08:00
    @Tairy 刚刚搜了下,http://ifeve.com/talk-arch-module/ 貌似这文章作者也是阿里那边的。
    就是系统解耦,按模块分割,每个模块可以高度扩展,扩展力很强,每个模块间以一种私有协议通讯,每个模块可以再无限分布式
    jswh
        73
    jswh  
       2018-01-05 16:47:35 +08:00
    xhprof 需要配合他自带的那个分析工具看。里面会显示出来每个函数的调用次数和总时间分配,一层层看下去就知道哪里慢了
    puritania
        74
    puritania  
       2018-01-05 17:35:01 +08:00
    Larvael 慢没得洗,在微服务这么流行的现在,框架带来的作用越来越小了。
    zhujiulin
        75
    zhujiulin  
       2018-01-05 19:28:58 +08:00
    你确定是 laravel 的锅? 一般 php 很少出问题,mysql io 网络依赖会导致 php 进程一直挂着释放不了
    0x8C
        76
    0x8C  
       2018-01-05 19:29:36 +08:00
    换 php7.2.1 试试,可能是 7.2.0 的 opcache 类型推论引起的性能问题
    Fishdrowned
        77
    Fishdrowned  
       2018-01-05 22:38:29 +08:00
    @wekw 这个框架就是在生产环境中一步步提炼出来的,最后才开源,虽然没什么人用,请你不要张口就就喷没价值。
    Veigar
        78
    Veigar  
       2018-01-06 00:40:10 +08:00
    @HYSS 用的 redis 当数据库
    abccccabc
        79
    abccccabc  
       2018-01-09 09:26:29 +08:00
    @wekw 你好,在用 phalcon 框架中,你觉得整体速度不会太快,会是出在哪个地方呢? Yaf 的功能过于简单,要 composer 数据库类、助手类、其它要用到的类,好累呀。

    @Tairy 你有查过 php 慢日志没?既然出现了性能问题,这个是要重点分析的。
    sagaxu
        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 估计就跟楼主那个一样了。
    Tairy
        81
    Tairy  
    OP
       2018-01-10 09:50:55 +08:00
    @sagaxu
    1. session 有些功能有用到,所以没有关。
    2. 路由确实 100 多。
    3. middleware 也有用到。
    sagaxu
        82
    sagaxu  
       2018-01-11 13:37:22 +08:00
    @Tairy 加上 seession 和那些 middleware 之后,别的 FPM 下跑的框架也不会快太多。你现在有两个比较合适的选择,一是用 Swoole 适配 Laravel,二是把部分瓶颈 API 重构成 Go 语言。第一个方案已经有不少人做过了,可以找得到例子。第二个方案是最近一两年很多公司的选择。100 个 API 里,访问量高的,可能也就不到 20 个。
    Tairy
        83
    Tairy  
    OP
       2018-01-12 09:35:21 +08:00
    @sagaxu 嗯 我正在用 yaf 把访问量高的 API 做重构。
    wekw
        84
    wekw  
       2018-01-12 10:36:24 +08:00
    @abccccabc 这个框架毫无扩展性,底层设计不合理导致需要用 PHP 做很多扩展,最后自然就变差了。我们要坚定 Laravel 不动摇,这货绝不只是开发效率高,其架构对大型系统也是非常合理的。
    sxdubin
        85
    sxdubin  
       2018-01-12 11:11:17 +08:00
    打印一个"Hello world",Laravel 需要初始化 30 多个实例,主要的消耗在于磁盘 IO,导致 CPU 使用率升高,建议尝试下 Laravel 和 Swoole 的结合,在代码全部加载到内存中,我们这边最近也在使用这个,效率提升 10 倍没有问题的。
    kylesean
        86
    kylesean  
       2018-01-19 22:25:59 +08:00
    SQL 优化了吗?
    imbo
        87
    imbo  
       2018-12-14 14:24:43 +08:00
    laravel 确实慢,laravel 用了许多反射,影响性能,数据库比较吃内存,建议换框架吧,老铁,推荐 slim 框架
    imbo
        88
    imbo  
       2018-12-14 14:29:58 +08:00
    Tairy
        89
    Tairy  
    OP
       2019-05-09 19:15:15 +08:00
    最近更新了一下,欢迎拍砖
    NtosKiking
        90
    NtosKiking  
       2019-05-14 13:33:35 +08:00
    学到了
    abccccabc
        91
    abccccabc  
       2021-08-25 16:54:07 +08:00
    @Tairy 最终用了 yaf 来写接口?那数据库操作使用那个 orm ?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   913 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 20:16 · PVG 04:16 · LAX 12:16 · JFK 15:16
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.