@gouchaoer 这类业务我们已经用了 swoole 常驻内存，fpm 里还剩一些暂时没迁移完的业务。性能要求很高的业务，跑 JVM 上了，性能要求高的基础设施，是 Java,C++和 Go 做的，PHP 做起来太累太麻烦。

swoole+php7 基本上可以榨干 php 的性能了，swoole 的协程用起来也还可以，虽然没有 go 语言方便。

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

@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 已经算不错的了。

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 多万能办妥