在国内使用 laravel 开发的公司多吗，这么优美的框架开发起来是不是很舒服？

@sagaxu
这不是我说的啊，作者表示我很为难啊，到底是哪国人了
https://tanronggui.xyz/t/342074
https://tanronggui.xyz/t/250863
https://www.zhihu.com/people/evanyou

尤雨溪不会搞艺术的程序员不是好设计师
居住地
现居新泽西
所在行业
互联网
职业经历
Vue.js · Chief Procrastination Officer
Meteor · Core Dev
谷歌 (Google) · Creative Technologist
教育经历
Parsons School of Design · MFADT
柯蓋德大學（ Colgate University ） · Art & Art History
个人简介
http://evanyou.me
https://github.com/yyx990803
http://vuejs.org


另外你举例的问题是页面太狭窄了，打个比方，日本流行游戏制作框架 http://www.nscripter.com/
https://onscripter.osdn.jp/
都是很少英文的，有也只是一部分，但是他就是成功了呀。
人家日本可以用国产，怎么到我国来就是不使用英语作为第一语言的就一定不成功了。
真是奇了怪了，又是外国的月亮更圆的论调？

开发时顺的一 B，压测时慢的一 B

曾经因为这个框架离职一家公司，这个框架封装的太狠，性能又差，你框架再怎么优雅，里面写的一团糟，也是垃圾！后来听里面同事说，4 台 8 核机器扛不起每秒 1000 人访问，然后准备通宵改原生！

@lianxiaoyi 8 核……就算是前几代的双路 x5650 也有 12 核了。
双路 x5650 的成本算 500 刀一台，就算上 10 台也就 5000 刀，差不多是 1-2 个工程师的月薪而已。
只有在工程师月薪惨不忍睹的情况下才值得花钱去改原生。

@ovear
vue 作者是复旦附中毕业的，大学才去的美国，就成美国人了？

点开一看首页还是英语多于日语，https://onscripter.osdn.jp/onscripter.html，而且这个并不能算主流游戏引擎，英文文档不好，是出不了日本国门的。跟 ruby 相比，恐怕你举的例子，流行程度接近于零了吧。

IT 发源地是美国，前沿技术和概念也大都来自美国，不用英语，等于主动把自己排除在最大最强的社区之外了。
如果 linus 当年用芬兰语，C++，C#和 PHP 之父都用丹麦语，python 之父用荷兰语，可能都要无人问津了。

不是哪国月亮圆的问题，IT 技术的东西，英语圈就是绝对垄断了，日语圈不行，德语圈也不行，法语圈也不行，汉语圈当然也一样不行。把自主和国产拿出来说事的时候，已经是玻璃心和深深的自卑感了。

@msg7086 你要开始这么比了，那就进怪圈了。

@lianxiaoyi 我倒想知道是什么情况导致了性能如此之慢。比如是否运行在生产模式，以及是否开启了 OpCache。

嫌臃肿的，性能敏感的项目就不要用嘛……用 Slim 呀 Lumen 之类的微框架不就好了
用 Laravel 的话，开发速度肯定要比微框架 /原生快得多（当然你写个 Hello World 之类屁大点玩意肯定是感受不到的），而且性能问题可以堆钱解决啊 :D 没钱又要高并发，参见上一句

我用于练习 PHP 而写的一个项目（ printempw/blessing-skin-server ），从 1.0 时代（原生 PHP ）到 2.0 时代（模型控制器分离，初有框架雏形）到 3.0 （自己写的 MVC 框架）到 3.1 （ Laravel ），过程中学到了很多。对于业务逻辑有一定程度的项目，Laravel 可以显著提升开发速度。我在这个项目前期摸爬滚打搞出来的一些东西，最后发现 Laravel 里全都有 :)

不过我还是不推荐 PHP 新手直接上手 Laravel，只会一个框架却完全不了解框架的内核，不好。

Laravel 臃肿的封装、缓慢的运行速度都是广受诟病的（也有 Laravel-Stone 之类的 solution ），不过其多层封装带来的好处，在业务逻辑复杂到一定程度后就会凸显出来。上面有些人吐槽「写个 Hello World 调用栈都有 70 多层」的人就是这样 :P

业务逻辑很简单的话，就不要用 Laravel 这样的全栈框架了。感受不到 Laravel 带来快捷开发的爽快感，你只会得出「垃圾框架，臃肿性能慢，优雅个 P 」这样的结论 ;)

我感觉好多人都跑题了，laravel 在 PHP 社区里的确是个很好的框架，和 springboot 其实没什么可比性，语言就不一样啊

@lianxiaoyi

laravel 是慢，但也没有慢到连 1000rps 都扛不住，laravel 之父亲自做过 benchmark
https://medium.com/@taylorotwell/benchmarking-laravel-symfony-zend-2c01c2b270f8

2G 内存的双核 VPS，20 美金一个月的那种，一个高级 php 开发的每月工资支出，可以买 200 个这种主机了
Without Sessions:
Laravel: 609.03 requests per second (mean)
Zend: 559.91 requests per second (mean)
Symfony: 532.97 requests per second (mean)

With Sessions:
Laravel: 521.64 requests per second (mean)
Zend: 484.94 requests per second (mean)
Symfony: 439.37 requests per second (mean)

1000rps，只要四核就搞定了，4 台八核搞不定，我觉得他们要优化的不是框架，是研发团队自身

@msg7086
你去看看 github 上的 php framework benchmark 那个 repo 吧，不只有 cpu 消耗，laravel 的内存消耗也惊人

https://github.com/kenjis/php-framework-benchmark/blob/master/README.md
这内存消耗，你 php-fpm 能开几个 worker 进程？

@gouchaoer 引文：「 laravel 我是真的读不懂源码，也没法单步调试一次请求，因为里面都是 closure 和啥 bus，各种跳来跳去，不懂」

Laravel 中的 Bus 应该是译为「总线」。而且读不懂框架内部实现哪有怪框架的？

@sagaxu 刚进去看了下压测参数 有点感人。。。ab -t 10 -c 10 http://server.address/

https://github.com/kenjis/php-framework-benchmark/的测试，本地搭了一个测试了一下


做了一点小小的 patch，不然用例是错的
https://gist.github.com/anonymous/5df1541bdbfa7b8cfe5513a361612893


结果如下，
|framework |requests per second|relative|peak memory|relative|
|-------------------|------------------:|-------:|----------:|-------:|
|ci-3.1 | 5,778.00| 6.8| 0.38| 1.0|
|slim-3.0 | 4,808.94| 5.7| 0.56| 1.5|
|laravel-5.3 | 849.19| 1.0| 2.04| 5.4|

注释掉 laravel 中默认开启的，但是无用的 middleware 之后，结果如下
|framework |requests per second|relative|peak memory|relative|
|-------------------|------------------:|-------:|----------:|-------:|
|ci-3.1 | 6,256.39| 4.3| 0.38| 1.0|
|slim-3.0 | 4,977.89| 3.4| 0.56| 1.5|
|laravel-5.3 | 1,453.05| 1.0| 2.02| 5.3|

把 fpm 的 max_children 从 2 改为 1，结果如下
|framework |requests per second|relative|peak memory|relative|
|-------------------|------------------:|-------:|----------:|-------:|
|ci-3.1 | 3,293.76| 4.1| 0.38| 1.0|
|slim-3.0 | 2,583.93| 3.2| 0.56| 1.5|
|laravel-5.3 | 803.36| 1.0| 2.02| 5.3|


laravel 跟 slim 和 ci-3.1 相比，在 hello world 的比拼下是比较慢，但是也绝对不是 1000rps 都扛不住的地步。
而且真实的业务，不可能就是输出一个写死的 hello world，业务逻辑自身有 php 代码，还要访问 db 和 cache，这些大部分占执行时间的代码都是一样的，框架执行时间只是小部分，框架占用的内存也只是小部分，把只占用 20%不到的资源，优化提高 100 倍，也只是把开销从 100 减少到 80 而已，这点儿性能提升或者内存减少，毫无价值。


最后，把性能拿出来说事前，得先把日 PV 做到 3000 万以上，否则那点儿访问量用什么还不都一样。

@你的 3kw 的 pv 平均下来就是 1000 的 qps 了（每天算 10000s 的访问时间），前面人也所说了 4 台 vps 扛 1000qps 都想换，你再看看内存，laravel 内存消耗是 ci 的几倍。。。

php7 平均下来提高一倍的 qps 都促使各厂升级，你哪里来的自信说 laravel 是 ci 的 1/5 的 qps 但是性能不重要？

@sagaxu 以上测试看起来有 3 倍多到 4 倍多的性能差距，RPS 是 1400，4900，6200，叠加上 RPS 不到 100 的业务逻辑代码之后，真实的 RPS 就变成 98, 99, 100，性能差距完全被业务逻辑代码给抹平了。

内存占用分别 2.02，0.56，0.38，看起来差距很大，如果业务逻辑自己占个 20M 内存，叠加上去，变成 22.02，20.56，20.38，差距还有多大？

这些 micro benchmark 最大的问题，是忽略了一点，业务逻辑自身消耗的 CPU 和内存才是大头，看似几倍几十倍的差距，一旦叠加上业务逻辑，差距就变得不再明显，因为那是加法，不是乘法。要知道，在局域网内走 TCP，几次 redis 访问就要几个毫秒了，真实场景下，单核的 RPS 是很难做到 1000 以上的，能做到 100 已经算不错的了。

业务逻辑本身不是很消耗内存的，大部分内存消耗是框架带来的啊。。。 @sagaxu

@gouchaoer 不用任何框架的 fpm 进程也占用 15-20M 内存了，这部分的确不能算在业务逻辑中，但是也不能随便把它从分子和分母中同时减去。而且业务也要看情况的，我们 fpm 进程内存限制到 128M 的时候，有些请求就报错了。有一些基础数据，是作为 php 代码 load 进来的，比如 371 个城市的信息，以及 371 个城市每个城市的配置信息，这些很容易就超过 2M 内存了。