@dawniii

先说内存的事，Java 和 Go 都有成熟的 GC，除非你开着全局变量并且一直往里塞东西，否则泄露不了内存，每个请求的 handler 是个闭包或者函数，只要不故意定义超过函数生命周期的变量，你不玩 off-heap 黑魔法，完全不会泄露内存。

部署的话，php 和 python 差不多，比起 Java 和 Go 麻烦太多了，Go 最简单，就一个可执行文件，大部分情况下也不依赖什么运行库。Java 比起 go 稍微麻烦一点，就是需要先安装一个 JRE，然后也是一个 jar 包直接运行(现代 javaweb 一般内置了 tomcat 这类 webserver)，复杂一点就是把 war 扔到 tomcat 的 webapps 目录，它会自动重启。

php 和 python 就麻烦很多了，用 pip/pear 安装扩展的时候经常会遇到 xxx.h 找不到，典型的比如 db 驱动。然后还必须前置一个 nginx 或者 apache，fastcgi 配起来还麻烦，不同框架配置方法不一样，还要提防 cgi 的 fixpath 问题。python 稍微好一些，uwsgi 比较简单，或者直接走 http 协议更简单。Java 和 Go 的最简单，把 static 资源外的直接 proxy_pass 走就行了。
PHP 光是把环境搭一遍都很麻烦。

php7.1 开始内置代码的 cache 了，改 php 文件是没用的，改完文件得重启 fpm 进程才能生效，这个应该是性能增强带来的副作用。在需要重启服务以后，php 的新版本手动部署，已经跟 java 或者 go 没有不同了。




觉得 php 部署简单的，我提个前几年遇到过好几次的场景，看看大家有没有好办法。

几台服务器，无外网连接，系统有 rhel5 和 rhel6，还有 ubuntu12 和 14，还有 windows 32 位和 64 位都有，用到的数据库是 pgsql 和 db2，如何打包 php 程序过去部署？

当时我的解法是，Java 给每个平台下载一个 JRE，应用打成 jar 包就好了，db 驱动也是 java 实现的，直接打进 jar 包里了，不依赖运行库。php 真的难倒了我，最后，我给每个平台下载了对应版本的 vmware，然后为 php 制作了虚拟机镜像，把兼容性工作交给了 vmware 去做。还好那些机器都有图形界面和 root 帐号，不然还得折腾无 gui 甚至无 root 的情况下怎么安装 vmware。

家具城各种类型都有，尺寸还能定制

过两年来杭州，杭州有 v 友线下聚会吗？

是计算机专业毕业的吗？如果不是，大概有 10 几门用得到的专业课需要过一遍，基础是速成不了的。

@beker 公司信息和薪酬福利完全没有，只说要求不说待遇，国际一线大厂也没这么傲慢

64 位系统和 32 位软件搭配时，也会报这个错，32 位库要单独安装

confluence

要求写的有点粗糙

Realforce 87u，价格便宜量又足

@dawniii php 的无状态那不是优势是劣势，无状态是架构上的，节点之间对等可替换，但是节点自己，需要记住一些自己的 metadata，内部是需要状态的。

@gouchaoer 和我直接有关的那个 case，没法跟 fpm 对比，不用 swoole 协程得开 1000 到 3000 个 fpm 进程，吃不消。如果不用 swoole，只能 Java 或者 Go 了。其它迁移到 swoole 的项目，CPU 降低了很多。因为 swoole 是我们厂维护的，所以不大可能考虑其它标榜高性能的 php 框架。

@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

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

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