3个接口都是内部api使用的，访问量在5000rps左右，公司的业务处理和api层都是用PHP做的，我觉得这3个接口（一个读db的，一个读redis的，一个curl到平台服务的）逻辑简单，没必要用php来做，直接用openresty做好了，效率肯定只高不低，结果在提交之后被大头否定了，然后举了hiphop的例子，认为如果想快，就去让hiphop支持我们的代码就好了。。唉:-(
第 1 条附言 · 2013 年 6 月 16 日
昨天在G+上竟然看到了有人转了下这个帖子，我就把这个坑填了吧。
最后程序上线了，但是不允许再往openresty迁新的接口了。
之前是nginx * 1 + fastcgi * 5（php-fpm设置的最大进程是1000，ondemand，fastcgi独立机器），程序走统一的frame，frame里有router，orm，用pdo，phpredis，curl。
走db和redis的平均响应10ms，curl的18ms。
迁移之后，用openresty * 1(和另一个标准的nginx共用一台机器), 机器的cpu 不到30%，db和redis接口的平均响应 < 2ms, pass proxy到平台服务的14ms。
无论是机器数，还是响应时间，openresty都完胜，不在同一个level上。
当然，openresty里的程序没有统一的frame，稍微占了点便宜。但是引入一个frame，估计对响应时间影响不大，即使增加50%的时间，也是非常客观的。
顺便问下，国内有哪些公司用openresty了？
最后程序上线了，但是不允许再往openresty迁新的接口了。
之前是nginx * 1 + fastcgi * 5（php-fpm设置的最大进程是1000，ondemand，fastcgi独立机器），程序走统一的frame，frame里有router，orm，用pdo，phpredis，curl。
走db和redis的平均响应10ms，curl的18ms。
迁移之后，用openresty * 1(和另一个标准的nginx共用一台机器), 机器的cpu 不到30%，db和redis接口的平均响应 < 2ms, pass proxy到平台服务的14ms。
无论是机器数，还是响应时间，openresty都完胜，不在同一个level上。
当然，openresty里的程序没有统一的frame，稍微占了点便宜。但是引入一个frame，估计对响应时间影响不大，即使增加50%的时间，也是非常客观的。
顺便问下，国内有哪些公司用openresty了？
23 条回复 • 1970-01-01 08:00:00 +08:00
 |
1
harryyyt 2013 年 5 月 29 日
遇到和LZ类似的问题，比较了Openresty，Node.Js和PHP三种方案，还是用Openresty的ngx_lua实现最快。也考虑过用hiphop，不过这玩意捣腾了半天还是没弄起来...我想既然是优化性能就用性能最佳的方案好了，不过上头可能是基于会lua的人不多的原因考虑
|
 |
2
rebellion 2013 年 5 月 29 日
楼主的头像好幸福的样子
|
 |
3
qiongqi OP @harryyyt 我们代码里用了namespace，貌似hiphop不支持这个。。头的意思是自己改hiptop。。我觉得有把hiptop改好的能力，n个openresty都学会了
|
 |
5
lookhi 2013 年 6 月 16 日
hiphop facebook?
|
 |
7
raincious 2013 年 6 月 16 日
不用hiphop那么麻烦。
可以等PHP 5.5上线之后+opCache一起用，很轻松就能优化到10毫秒左右。 |
|
8
qiongqi OP @raincious PHP 5.5是等不到了，已经有同事在弄hhvm了。
其实我对hhvm一直没有一个系统的认识，google也没有找到hhvm跟apc，eAccelerator的性能对比。 感觉hhvm提高的有限，已经是跟apc一个级别的。 还是跟openresty这种杀手级的应用不在同一个level上。 是不是，PHP就不太适合做访问量很大的api使用？ |
 |
9
tedeyang 2013 年 6 月 23 日
确实会破坏架构，领导也要考虑测试、发布、维护、招聘的成本。
|
 |
10
min 2013 年 6 月 25 日
妥妥的异端啊，搁早几百年绑十字架上一把火就把lz你给点了 ^_^
|
|
11
qiongqi OP @tedeyang 确实会有这个问题，但是我还是不觉得当摊子大了以后，还是都依靠php来做，看看facebook，现在估计想迁个接口都迁不动了。
|
 |
13
Sunyanzi 2013 年 6 月 26 日
leader 人很好啊 ... 他自己觉得是异端但是至少他会看数据然后屈服于更好的技术 ...
另外说 hiphop 远比各种 OPCACHE 提升得要多 ... 因为一个是重编译一个只是缓存 ... 说来这得是多大的公司才会自己组团研究 HHVM 啊 ... 至少八十人的开发团队 ..? |
 |
14
notedit 2013 年 6 月 26 日
我比较赞同你们的leader 把架构搞复杂了 带来的维护成本更高
比如你的lua代码有人维护么 可以很容易的进行单元测试么 可以很容易的继续集成么 |
 |
15
mudone 2013 年 6 月 26 日
在一个组织里做东西，leader更多的考虑到如果你离开后这部分的东西如何处理和维护。
|
|
16
min 2013 年 6 月 26 日
facebook里已经有hhvm教派了，教义完备信众一大帮，自成体系,和php信的不是一个神
你们公司都信默罕默德的，就你一个哭着喊着要说猪肉挺好吃，让大家一起吃，能有好结果么你 ^_^ |
|
17
qiongqi OP @Sunyanzi leader人不错的。我们部门没有那么多人，只要有同事去测试hhvm的性能了，之前说的修改hiphop也就是leader随口一说
|
|
18
qiongqi OP |
 |
19
zhangxiao 2013 年 6 月 26 日
@qiongqi 你把tests写好再拿去劝x爷。还可以把你写的部分部署成替补或者灾备，万一性能出问题了能立刻顶上也不错，但是估计你需要自己花时间去保证这部分的更新了...
|
|
20
qiongqi OP @zhangxiao 更新不费劲，没有什么新的feature了，就是老的一大堆，也没人负责，删掉的话就跳了一堆人不同意。。现在都是我自己有时间的话，写着玩。。最终能成型的话，就放github上
晓哥在那边滋润不？据说那里一年有半年放假？ |
 |
22
cloudzhou 2013 年 6 月 26 日
看情况，如果我是 leader 的话，不到遇到性能问题，或者准备架构更新，是很难支持异构的。异构遇到的问题只有后来才深刻体会。
|
 |
23
huaiyinhou 2013 年 8 月 18 日 via Android
@qiongqi 选这个主要还是与业务系统有关与已有架构。
|