Laravel 性能问题始终难以释怀,求指点

问答 yyyang ⋅ 于 2017-01-07 00:15:56 ⋅ 最后回复由 wyg27 2017-01-18 01:03:36 ⋅ 1299 阅读

似乎众所周知laravel的性能在诸多PHP开发者口中总是被诟病,本人不服实测了一下,发现最小MVC应用下Laravel比tp5,yii2慢2-3倍,在国内PHP圈好像特别重视性能,yii2和tp5都要在官网上宣传自己性能出众好像才符合套路,在企业级应用上yii更受青睐,淘宝途牛等都在用yii,不知道laravel有哪些大企业在用,还有就是性能问题会不会成为在国内推行的最大障碍

准备用laravel开发项目,但是说服不了自己,求各路大神指点,谢谢!@Summer

本帖已被设为精华帖!
本帖由 Summer 于 1周前 加精
回复数量: 21
  • leo MOD 不会写前端的后端不是好运维
    2017-01-07 00:18:39
    1. 绝大多数项目活不过性能撑不住的那天(除非你的sql写太烂)
    2. 框架本身的性能达到瓶颈加机器就是了,可以无限横向扩展,又不是BAT级别的访问量,多一两台服务器成本高不了多少
  • Scholer
    2017-01-07 00:20:09

    其实到没觉得国内的PHP圈真的多重视性能。
    项目起步阶段性能也绝对不是第一参考因素,如果高效切入、节约时间并能约束好发展路线才是最重要的。至于性能,我觉不是你能在一开始就能想清楚的。
    还有一点:烂代码和烂的结构设计,不合理的数据库使用方式带来的问题比框架本身的问题要大太多了。

  • Summer MOD A Life-long learner.
    2017-01-07 07:29:12

    @leo Leo 哥已经说得很好。

    以下个人观点,仅供参考。

    作为「应用工程师」,性能的事情,永远不是问题,开发高效、趋势,才是要重点考虑的东西。

    PHP 不也一直被人骂慢吗?相对于其他如 C/C++/Java 等语言框架,PHP 实在是太慢了。问问你自己,你为啥选择 PHP ? 不就是因为他的开发高效和趋势么。

    2017 年,随着 PHP7 的出现,PHP 已经不慢了。这就是趋势的力量。

    另外问一句,你觉得 https://laravel-china.org 慢吗?LC 就是构建在 Laravel 上的。

  • chenyuanqi 最懒进化
    2017-01-07 08:30:30

    laravel 是为艺术而生的框架,而 PHP 的高版本已然对性能做出了很大的进步。
    之所以国内少有大企业使用 laravel,恐怕考虑的不只是性能,而更多的是开发成本吧~

  • 远客 收住心,全力拼
    2017-01-07 09:33:28

    赞同楼上几位的观点,目前的阶段,性能不是首要考虑的因素,开发高效才是最重要的,性能不行,多加一台机器就搞定,开发效率慢,你得多招几个人才搞得定?可以想像多招一个人和多配置一台服务器,哪个成本更大?再说了,好好想想,你的项目能扛到性能爆表那一天吗?

  • 远客 收住心,全力拼
    2017-01-07 09:35:07

    @chenyuanqi 以前是熟悉laravel的少,但是现在流行起来,熟悉的人也多了,以后用 laravel 的企业会越来越多,我这边的项目,果断转到 laravel 了,最近这一两个月都在给项目组的人培训 laravel ,大家上手都很快

  • phpcws
    2017-01-07 13:28:56

    @leo 赞同leo的第一个观点!!!

  • bluetoothswh LaraStore商城系统
    2017-01-07 14:37:23

    主流的PHP框架的性能都差不多,没觉得那个PHP框架性能有多拔尖。Laravel的高开发效率,良好的代码风格为项目的持续开发提供很好的保障。如果配合上 redis缓存 + 云存储(阿里OSS或者七牛存储) + 服务器上SSD硬盘 + 适当的优化,性能可以妥妥的!放心用吧

  • 陈钦成
    2017-01-07 16:28:15

    @Summer 我觉得LC慢啊 如果用tp5可能快点

  • benjy
    2017-01-07 19:20:55

    性能无需担心,除非是一线的应用;
    laravel的学习成本高,轮子多;是否会有这样的情况,项目中使用了某个轮子,若干时间后laravel升级了,但这个轮子和新版的laravel不兼容了,更糟的是轮子的作者已经不维护了。。那么自己升级轮子或者laravel不升级,是不是有一些尴尬?

  • JobsLong MOD 那么,下一步的行动是什么?
    2017-01-07 20:00:04

    @benjy 商业项目考虑使用 LTS 版本

  • zhuzhichao MOD Lalala Demacian !
    2017-01-07 20:09:18

    以下两点我要指出。

    1. 不要轻易、任性、随意添加各种各样的 package ,特别是需要添加 provicder 的那种,捡最需要的来。
    2. 模型的 Observer 多的话,确实会影响框架启动速度,当前的项目有二三十个,影响10~40ms的启动速度(服务器配置不一样,影响不一样),这个没办法处理了。

    上面这两条是我的项目确实存在的问题,并且确实对哪怕一个 hello world 的简单输出也要有影响,但是很难处理掉的。

    其他的挺好的,laravel 对我们的项目的进度和开发的质量真的相比其它框架提高了很多。并且线上的 8核16G OPCache,影响不太大,项目现在有100多个表,业务密集型的应用,速度满足我们的需要,大部分页面和接口 200ms 以内。

    最后,SQL 一定要处理好,这个可能永远是你们项目性能最大的瓶颈。 :swimmer:

    laravel 开发起来挺嗨的,确实挺嗨的

  • xhh110
    2017-01-08 00:34:21

    https://segmentfault.com/a/1190000007894118

    file

    你可以试试啊 反正我是还没到达考虑性能问题的时候

  • MrJing MOD
    2017-01-08 08:55:21

    项目的可维护性,是相对更加重要的。用框架损耗一点性能,来换取开发效率、可维护性是值得。至于优化性能,手段很多,一般找到性能瓶颈对其优化即可,而性能瓶颈一般不会是在框架上。
    比如:用 Laravel 比用XX框架,框架多消耗了 50ms。但是你发现流量上来后,瓶颈是在 IO 上(比如数据库,服务器硬盘,网络 IO)。假如可能是 mysql 数据库查询就慢了 1s。这时候要引入缓存,就可以解决该阶段的问题。在实施方案时,发现用XX框架加缓存,代码写得乱七八糟,漏洞百出。而用 Laravel,花了很短的时间和精力就上了缓存功能,并且代码优雅,结构清晰,易于维护。那么,框架的优势就体现了。

    实在“说服不了自己”哩,就不要勉强啦,开心最重要。

  • JokerLinly 小渣渣的进击之路
    2017-01-08 10:06:39

    @Summer 很强势 :smile:

  • chongyi
    2017-01-10 09:44:22

    @leo 这个观点刚开始我是赞同的,不过现在我觉得仅仅只拿出这几条还不够。

    不过我先针对楼主的情形直接说答案:你如果明确地知道你的项目是什么类型,包括明白一些细枝末节的东西的话,你与其担心这个,不如先把规划做好,否则你选择任何一个框架,最终结果都是跳入深渊。

    我觉得讨论性能问题有很多限定条件,并不能说开发阶段不要担心,虽然大多数情形是这样的,即要不是瓶颈根本不在框架,要不就是加机器就很容易解决。但毕竟不能抛开项目本身不谈,所以各类因素往往很复杂,三言两语也说不清楚。

    最大的决定因素就是,项目本身类型和使用对象。其次就是整个产品周期的安排以及运营方案。

    不是所有项目都是依赖数据库的,根本不存在大量 IO 的系统比比皆是。亦或者频繁的计算和 IO 并存的。对于 IO 密集型应用,不去做优化,你拿什么语言,差距都不会十分明显的,这种情景解决方案就非常多了,根据需要选择,框架毕竟是给提供工具集的东西,因此或多或少都会提供一些简单有效常用的解决办法,如果没有提供,也只不过将由框架做的变成了由你做的罢了。

    对于密集计算,这个和语言本身、框架的设计就有着相对而言比较紧密的关联了。Laravel 弱在其生命周期中参与的部分实在太多,调用堆栈之长,你会发现框架给的那些优化方案其实都是杯水车薪。虽然我在这里这么说,但不意味着你真的会遇得到,就算遇得到,那么你拿任何语言、框架你也都遇得到,只是恰好 Laravel 放大了这一切。具体优化方案和 IO 密集一样有很多,但都脱离了 Laravel 本身,因为这些解决方案,并不影响你是否使用 Laravel,不过这取决于你的基本功,如果你把代码写的很糟心,那么重构可能更好。

    还有使用对象,项目使用对象决定了你开发的优先保障目标,面向外部人群和面向内部的系统思路可是不一样的,毕竟外部的不确定因素更多,说到这里你应该能明白。

    最后,产品周期安排是你必须在开发初期选择框架时就要关注的,如果草草上线,作为负责的有态度的开发者,明明知道面向客户群体复杂且庞大、系统涉及关键节点及其庞杂,这时候你更应该选择一个你更为熟悉的框架,不应该被各类广告、宣传、以及自来水冲昏头脑,否则最终你会为你的一时爽买单。很显然我就是其中的一员,不过这样也逼着我背下了一半的 Laravel 源码,我现在已经可以做到默写 40% 的 Laravel 框架了,只要放出新特性描述我都可以做到自己先实现起。

    总结,Laravel 的确是一个高效且优雅的框架,作为其重度使用者的我也觉得这个框架已经被神话了。如果你有足够的时间且理解你所开发的项目,真心推荐使用 Laravel 作为项目开发框架。但是,如果,就像我说的,如果你对项目做不到知根知底、PHP 基础不扎实、周期紧张、项目影响大,所有综合因素来判定后,慎重决定。如果你真的很希望使用且愿意为后果买单,像我这样愿意深入学习其优秀特性、思想,仔细阅读文档、源码,做到举一反三甚至能做到任意改造且升级自如,那么,你还会提出这种问题吗?

  • chongyi
    2017-01-10 09:45:46

    再补一句,什么框架语言,真的不重要,人才是最重要的。

  • yyyang
    2017-01-13 03:37:43

    感谢大家的热情解答,谢谢各位!

  • young Code is Poetry
    2017-01-16 12:57:44

    Taylor 才写了一篇关于各框架性能比较的 文章。可是看起来Laravel也没啥性能问题 :no_mouth:。前面各位大牛都已将说的很明白了,任何问题都必须针对特定的技术场景。如果 我现在目标就是做一个 BAT 级别的产品,那我都不会考虑用 php,如果我只是快速进行产品开发,那 Laravel 必定是我第一首选。任何问题请留到可能会出现的那天再去考虑怎么解决,过早的优化是万恶之源!

    无比赞同Taylor的观点 :raised_hands:

    file

  • jasonchang
    2017-01-17 15:38:20

    @yyyang laravel 确实慢,但是不至于差很多,laravel 节省出来的开发成本,远比增加服务器大。
    还有几个基本问题

    1. php7 用了吗
    2. opcache 开了吗
    3. optimaize 了吗
  • wyg27
    2017-01-18 01:03:36

    评论中众多兄台的意见都说的差不多了,这里我只说说自己多年来的切身体会。我的经验是,除非你所在的公司或参与的项目很牛逼,否则的话,你写的代码难听点说不会存在的如你所想的那么久,就算真有那么久,届时你也未必还留在现在的岗位上了。因此,什么性能之类在某种意义上说根本就是“关你鸟事”,你要面对的只是如何快速的交付任务和下班,以及应接不暇的各种狗屎新功能,在这种环境下,一个好维护的代码要胜过跑得快的代码。

    退一步说,你是有志青年,想要写出一个性能出众的程序,我觉得追求这个层次的人应该不会只依靠框架了,具体的就多了,我也说不清楚。

    一个人从有激情到麻木妥协,很多时候并不是因为自己的沉沦,而是外界环境逼你如此,没有选择。有空玩玩一个独立游戏《Inside》,之后你会有同样的感悟。

暂无评论~~
  • 请注意单词拼写,以及中英文排版,参考此页
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`, 更多语法请见这里 Markdown 语法
  • 支持表情,使用方法请见 Emoji 自动补全来咯,可用的 Emoji 请见 :metal: :point_right: Emoji 列表 :star: :sparkles:
  • 上传图片, 支持拖拽和剪切板黏贴上传, 格式限制 - jpg, png, gif
  • 发布框支持本地存储功能,会在内容变更时保存,「提交」按钮点击时清空
Ctrl+Enter