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

Laravel 到底能慢到什么程度?

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

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

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

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

    88 回复  |  直到 2018-12-14 14:29:58 +08:00
        1
    mchl   2018-01-04 19:44:34 +08:00 via iPhone
    搜 laravel opcache
        2
    Tairy   2018-01-04 19:45:42 +08:00
    @mchl 这些早都加上了,网上能搜到的优化方案都用上了
        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   2018-01-04 19:49:58 +08:00
    @kslr 还没查到确切的原因,用 ab 测试了一下 laravel 和别的框架,输出同样的内容 laravel 的表现堪忧啊。
        7
    flyingghost   2018-01-04 19:50:53 +08:00
    @akira 请教如何找瓶颈?
        8
    Tairy   2018-01-04 19:51:27 +08:00
    @akira 能想到是瓶颈的地方都试过了,发现改了之后也没啥明显优化,现在唯一能想到的就是可能 Laravel 的性能真的不行。
        9
    assad   2018-01-04 19:52:06 +08:00 via Android
    这个框架性能上确实堪忧
        10
    Tairy   2018-01-04 19:52:42 +08:00
    @assad 大佬有实际使用经验么,达到什么量级就扛不住了啊。
        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 慢 做集群 😂
        18
    Tairy   2018-01-04 20:25:41 +08:00
    @gclove 这些都做过了。
    @des xphrof 之后输出一大堆,没办法看,求问有没有看这个的经验。
        19
    qiayue   2018-01-04 20:25:41 +08:00
    数据库加索引没有?
        20
    Tairy   2018-01-04 20:26:10 +08:00
    @qiayue 这个肯定加了,能缓存的基本上都缓存到 redis 里面了。
        21
    gclove   2018-01-04 20:28:46 +08:00
    @Tairy 感觉要达到你描述的效果,至少要很多的请求流量啊。

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

    架构,业务规模,初步性能分析,监控数据、日志,就这些都没有,难道靠“感觉”优化吗?
        24
    Tairy   2018-01-04 20:34:24 +08:00
    @tomczhen 提问的时候没写太多,只是想找找看有没有相关经验的朋友,之后回跟进相关的信息的。
        25
    des   2018-01-04 20:36:52 +08:00 via Android
    @Tairy 你搜索一下,网上介绍这个的文章多如牛毛,虽然都是相互抄的
        26
    TangMonk   2018-01-04 20:39:10 +08:00 via Android
    每秒 3000 已经很不错了好吧,还嫌不够就集群啊
        27
    Tairy   2018-01-04 20:41:16 +08:00
    @TangMonk 现在跑 13 台机器,有 8 核 8 G,8 核 16G 和 16 核 16 G 三种配置。
        28
    TangMonk   2018-01-04 20:43:53 +08:00 via Android
    @Tairy 13 台机器确实有点慢了,是不是有数据库锁或者其他阻塞操作?
        29
    Tairy   2018-01-04 20:45:53 +08:00
    @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
    刚给公司解决了瓶颈问题,重点还是数据库查询这一块,榨干每一个地方,用重型框架就是这样,业务没上来的时候看似没什么问题,一旦上来了问题就凸显出来了,加上有些同事写代码的时候不考虑性能,为了省事用现成的查询封装就为了取一两个字段而不去重新写查询逻辑,非常浪费资源
        32
    TangMonk   2018-01-04 20:50:22 +08:00 via Android
    @zn symfony4 还有些必要的 bundle 没有升级过来
        33
    l57t7q   2018-01-04 20:57:51 +08:00 via Android
    我这里 api 日访问量大概有 800w,单机无压力
        34
    Tairy   2018-01-04 21:00:40 +08:00
    @l57t7q 单机啥配置啊大哥。
        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
    #42 同意 Fishdrowned 的优化建议,Laravel + swoole。

    可参考: https://github.com/huang-yi/laravel-swoole-http
        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
    你机器的配置是什么?
        54
    wwek   2018-01-05 09:57:01 +08:00
    @dawniii 鸟哥语录没毛病
        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   2018-01-05 10:26:16 +08:00
    @jhdxr 真的不是黑 PHP,就是提出个疑问而已,我已经在抓 xhprof 研究了,占用 CPU 的就是 fpm,MySQL 是独立的主机。
        60
    kkeiko   2018-01-05 10:31:54 +08:00
    laravel 本身是不错的框架,和其他框架比,慢也是事实,但同时开发更优雅,解耦更强也是事实。根本上还是要看使用者要的是什么,但有一点可以肯定的是,从来没有万能的框架,laravel 也是如此,技术架构是要不断迭代更新来适应业务的。而不能说 laravel 在这个时间节点不适应你的业务就是不好的。
        61
    kkeiko   2018-01-05 10:34:47 +08:00
    @kkeiko 顺便给个建议,如果是小项目,维护的人不多, 放弃 laravel 吧,得不偿失。yaf 是最好的选择。
        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 通讯。。无敌的。。
    阿里有些架构就这么干的。。
        66
    Tairy   2018-01-05 11:45:04 +08:00
    @st2udio 我们之前 1200 发现 cpu 很容易爆,就改到 800, 基本上最合适了吧。
        67
    Tairy   2018-01-05 11:45:32 +08:00
    @YMB 小公司哪有这些。
        68
    sampeng   2018-01-05 13:42:11 +08:00
    加机器啊。。。。。能用机器解决的问题。干嘛用人来解决。程序员一年工资 10-30 万。一台机器一年才多少钱。。。
        69
    HYSS   2018-01-05 14:53:04 +08:00
    @Veigar 你没算数据库吧
        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 这个框架就是在生产环境中一步步提炼出来的,最后才开源,虽然没什么人用,请你不要张口就就喷没价值。
        78
    Veigar   2018-01-06 00:40:10 +08:00
    @HYSS 用的 redis 当数据库
        79
    abccccabc   2018-01-09 09:26:29 +08:00
    @wekw 你好,在用 phalcon 框架中,你觉得整体速度不会太快,会是出在哪个地方呢? Yaf 的功能过于简单,要 composer 数据库类、助手类、其它要用到的类,好累呀。

    @Tairy 你有查过 php 慢日志没?既然出现了性能问题,这个是要重点分析的。
        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   2018-01-10 09:50:55 +08:00
    @sagaxu
    1. session 有些功能有用到,所以没有关。
    2. 路由确实 100 多。
    3. middleware 也有用到。
        82
    sagaxu   2018-01-11 13:37:22 +08:00
    @Tairy 加上 seession 和那些 middleware 之后,别的 FPM 下跑的框架也不会快太多。你现在有两个比较合适的选择,一是用 Swoole 适配 Laravel,二是把部分瓶颈 API 重构成 Go 语言。第一个方案已经有不少人做过了,可以找得到例子。第二个方案是最近一两年很多公司的选择。100 个 API 里,访问量高的,可能也就不到 20 个。
        83
    Tairy   2018-01-12 09:35:21 +08:00
    @sagaxu 嗯 我正在用 yaf 把访问量高的 API 做重构。
        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   38 天前
    laravel 确实慢,laravel 用了许多反射,影响性能,数据库比较吃内存,建议换框架吧,老铁,推荐 slim 框架
        88
    imbo   38 天前
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2541 人在线   最高记录 4236   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 24ms · UTC 12:40 · PVG 20:40 · LAX 04:40 · JFK 07:40
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1