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 万以上，否则那点儿访问量用什么还不都一样。

@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 台八核搞不定，我觉得他们要优化的不是框架，是研发团队自身

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

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

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

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

@ovear

公司在技术选型搭配上可以有自己的一套，结合业务搞几个自己的组件或者服务，甚至搞一些内部的 boilerplate 项目，新项目直接从这些 boilerplate 开始，都是不错的积累，也是自成体系融入公司风格的。
重复攒一个别人已经做得很好的轮子，发起人可以评个资深或者架构师 title，但是对公司而言收益点在哪里呢？

vuejs 作者是上海人，去年加入阿里 weex 团队，怎么就不能算中国人了？日本在开源界最有名的是 ruby，英语文档不差，他们对 freebsd 和 postgresql 也有很多贡献。语言的确不是框架成功的要素，但是不把英语作为首要语言的框架，没有一个是成功了的，它是必要条件，不是充分条件。

@ovear

你忽略了人员流动性，项目是还在，但是人已经换了一波又一拨，用一个主流一些的框架，招聘接盘侠的时候可以尽量招用过这个框架的人，即便没用过，热门框架的文档和社区也不是自己的轮子能比的了的。

京东上很容易就能买到主流框架的书，但是自己的轮子，绝大部分连个像样的文档都没有，轮子创始人一离职就呵呵

@ovear 说的好像国外都万年 SSH2 一样，现在哪怕是国内，也就一些遗留项目在用 SSH2，springmvc 都是十几年前的东西了。国产不是掉价的原因，vuejs 就很棒，文档也不错，老外也喜欢用，以前 yii 也蛮受欢迎的。老外的框架，成功了的也就那么几个，每个语言主流的也就一只手数的过来，但是不管哪个国家的人搞的，文档一定是英语优先，再翻译成各国文字。

PHP 社区的确情况特殊，基础差的人太多，学过设计模式的太少，甚至还有看英文有障碍的半文盲，也没很多机会做大项目，一个在别的社区很平常的东西，到 PHP 社区就会有一堆人觉得复杂和过度包装，看一眼就嫌烦或者被吓倒放弃的不在少数。语言本身的限制，加上技术玩的好的普遍看不上 php，也就只能这样了。

@ovear 因为重的轮子，不是没能力造就是没精力造，即便造出来，多半也要扔的，用 C++重写 hadoop 和 spark 的事情，国内有大厂也干过，后来目的达到之后还是放弃了。一般公司 KPI 轮子，也会挑简单一些的下手，比如建议框架，建议 cache，简易 rpc 协议，简易配置服务器，不会傻到挑那些做到跳槽那天都没做完的东西。

每个互联网公司都有社区情节，每个做 web 的都有过框架情节，我敢说，100 个做过 php 的人，起码 90 个造过自己的简易框架，大部分可能简单到只有 url 路由和 load 模板，最多加个简单的 DAO 层，这些重复劳动其实没有意义。github 超过 5000 星的那些，才能说及格了，有存在的价值。

@ovear

jfinal 我今天第一天听说，常年混 reddit java 社区竟然没听人提过，它跟 springboot 有可比性吗？
稍微了解了一下，原来是中国特供，它模仿了 rails，对比过去的 SSH 是简单了一些，但是跟 springboot 比还是麻烦。

tornado 侧重点是 async，它代替不了 flask，pip 里搜一下就知道 package 数量差了几倍。
django 倒是能代替 flask，而且新手我更推荐 django，它更加的一站式服务，虽然比 flask 入门稍复杂一些。

laravel 的概念是新东西吗？都是别人玩腻了的，你做 php 的没了解过 zend framework 吗？概念一点儿都不比 laravel 少。
现在不是 2008 年之前，后端不再是个人单打独斗的时代了，团队协作和代码质量的问题频繁暴露，php 那套端平快的玩法，已经跟不上时代了，所以最近几年 php 一直在走下坡路，稍有规模的公司，要么完全不用 php，要么把 php 归为前端，只是拿来拼凑个页面或者组装后端 API 的返回值，PHP 已经很边缘了。laravel 给了那些代码规模大性能要求低的项目，继续使用 php 的便利。

PHP 不是我主力语言，但我用过 CI 和 Yii1，觉得它们过于简陋和麻烦，laravel 的出现让人眼前一亮，便利和强大兼顾了，而不是折衷了，牺牲掉的是一点性能，这点用 PHP7 可以挽回。去年有新项目需要用 php 时，随便看了一会儿 laravel 就上手了，从零开始也非常简单，它不过是把别人玩腻的东西挑选了一些用，都是早就熟悉了的东西，没什么新意。

@ovear 研发团队喜欢搞轮子，有的时候并不是业务真的需要重复造轮子，而是为了 KPI，轮子搞完，通道评审做完，可能就不大维护了，交给新来的人，新来的人可能根本看不上，又重搞一套。所以比较大的公司，team A 搞的轮子，同部门的 team B 可能看不上，甚至 team A 内部还分好几派，多种框架轮子并存。

@ovear

举个 python 的例子，flask 只是作者一个周末心血来潮搞出来的，它几乎没自己的东西，整合了 jinja 和 werkzeug，DB 整合了 sqlalchemy，signal 用的是 blinker，一出来就很受欢迎，很快就有了超过 10000 个 star 和 300 多个代码贡献者。然后涌现了一大堆的 flask-xxx 库，大都也是整合已有的库。flask 出现之前，早就有 pip 了，但是还是不够方便啊，要自己整合。

再看 Java 网红 springboot，它什么都没做，就是把 spring-xxxx 整合了一下，以前要自己写配置文件引入的组件，现在都变成一行配置搞定一堆，它有开创性工作吗？没有。它有属于自己的优秀的库吗？也没有。但是它很快就横扫 Java web 领域，因为它方便。它出来之前，用 maven 也能很快引入包，用 spring 的 di 也能几行代码配置起来，但是跟 springboot 比还是麻烦了一些。

刚入一个新语言的坑，有一帮摸爬滚打了多年的老司机给个菜谱，推荐一些不错的库，再给个 best practice 指引，迅速得到以往靠自己折腾几年才有的知识储备。这类自己不提供核心只做整合的框架，大大降低了入门门槛，也降低了很多重复自己多年的老手的价值。

@zsz

user 服务只提供 client side session 的 encode 和 decode，其本身并不需要保存 session 的内容，使用 cookie 保存 session 并不是楼主想省内存，楼主是选了 flask，flask 默认行为如此，并非楼主意愿体现。

早期可能不需要考虑太多规模上去之后的事情，业务进化的过程中，技术层面也会不断迭代。初期根本不用考虑多语言协作，也不用关注流量和性能，那是日 PV 过了千万之后才要面对的事情。

@ovear 框架要充分考虑通用性，所以会有非常多的 feature，项目中用到的可能只是其中很小的一部分。普通人连 excel 的百分之五功能都用不到，所以要用记事本自己排版做表格吗？

集成优秀的第三方库，而不是重复发明轮子，这也是 laravel 聪明的地方，它把 dirty 的整合工作给你做好了，节省体力劳动。就算你用 CI，一样有要整合第三方库的时候，总不能浪费时间造一大堆的轮子，除非你的项目小到不需要轮子或者大到成立平台组每年花几百万造轮子。

@zsz 不同语言开发，应该把 user 作为一个服务了吧，请求 flask 提供的 user 服务，取回 decode 过的 session，没难度啊

@ovear 你要从 lamp 开始搭，的确比较麻烦。我本来就是 linux 下做开发，lnmp 是现成的，composer 也是早就有了，跟一键安装没有太大差别。配置文件和环境变量是每个框架入手之前都要关注的，orm 可以不用，就像 CI 那样只用它的 querybuilder 也可以的。homestead 和 varigant 之类的，你根本不用了解，直接忽略就行了。

laravel 的价值不是封装的多好，是设施齐全方便，你需要 queue 的时候，它已经在那儿了，你要计划任务，它也有，别的框架里要自己整合的东西，很多它都能开箱即用免折腾。当你要封装自己的组件的时候，用它的方式去做也很简单实用。

@ovear 文档能看 6 天？我看了个把小时，搭环境用了几分钟，第一个功能当天就测试通过

@sorra 家底厚可以买上海户口，有黄牛帮你包装，前两年大概 100 多万能办妥

户口用处不是很大，除非你想买第二套房

@gouchaoer 对前端而言，就算你把 PHP 栈换成 Java 栈，他们也感受不到，完全兼容的。你觉得 Linux 内核兼容，是因为从内核到你的代码，要依次经过 libc，php 解释器，php 框架，兼容性工作在 libc 和 php 解释器那边就完成了。

升级确实不一定是一天，从 5.3 到 5.4，我不到半天就升级完了，minor 版本之间的 change，break 掉用户代码的情况是很少的，不放心可以读一遍 changelog 中不兼容的部分，对照的搜一下代码，花不了很久的。

那些没有足够开发资源的框架，版本才能够比较稳定，不更新 patch 以外的东西，甚至连 patch 都无力维护。

去年我把一个项目完整的从 Java6 升级到 Java8，所有框架和库从 2012 年版本直接跳到 2016 年版本，十几个基础库的大版本号跳了 1-2 个，算上测试在内，也就花了一天时间。刷版本号真不是什么大事，迁移成本也没有那么高，甚至不迁移也无所谓，老版本一直用下去好了。

程序很简单就重写一个 BS 版，买个 VPS 就行，刀片都省了