3个接口都是内部api使用的，访问量在5000rps左右，公司的业务处理和api层都是用PHP做的，我觉得这3个接口（一个读db的，一个读redis的，一个curl到平台服务的）逻辑简单，没必要用php来做，直接用openresty做好了，效率肯定只高不低，结果在提交之后被大头否定了，然后举了hiphop的例子，认为如果想快，就去让hiphop支持我们的代码就好了。。唉:-(
This topic created in 4908 days ago, the information mentioned may be changed or developed.
Supplement 1 · Jun 16, 2013
昨天在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了？
 |
harryyytMay 29, 2013
1
遇到和LZ类似的问题，比较了Openresty，Node.Js和PHP三种方案，还是用Openresty的ngx_lua实现最快。也考虑过用hiphop，不过这玩意捣腾了半天还是没弄起来...我想既然是优化性能就用性能最佳的方案好了，不过上头可能是基于会lua的人不多的原因考虑
|
 |
rebellionMay 29, 2013
2
楼主的头像好幸福的样子
|
 |
3
@harryyyt 我们代码里用了namespace，貌似hiphop不支持这个。。头的意思是自己改hiptop。。我觉得有把hiptop改好的能力，n个openresty都学会了
|
 |
lookhiJun 16, 2013
5
hiphop facebook?
|
 |
rainciousJun 16, 2013
7
不用hiphop那么麻烦。
可以等PHP 5.5上线之后+opCache一起用，很轻松就能优化到10毫秒左右。 |
|
8
@raincious PHP 5.5是等不到了，已经有同事在弄hhvm了。
其实我对hhvm一直没有一个系统的认识，google也没有找到hhvm跟apc，eAccelerator的性能对比。 感觉hhvm提高的有限，已经是跟apc一个级别的。 还是跟openresty这种杀手级的应用不在同一个level上。 是不是，PHP就不太适合做访问量很大的api使用？ |
 |
tedeyangJun 23, 2013
9
确实会破坏架构，领导也要考虑测试、发布、维护、招聘的成本。
|
 |
minJun 25, 2013
10
妥妥的异端啊，搁早几百年绑十字架上一把火就把lz你给点了 ^_^
|
 |
SunyanziJun 26, 2013
13
leader 人很好啊 ... 他自己觉得是异端但是至少他会看数据然后屈服于更好的技术 ...
另外说 hiphop 远比各种 OPCACHE 提升得要多 ... 因为一个是重编译一个只是缓存 ... 说来这得是多大的公司才会自己组团研究 HHVM 啊 ... 至少八十人的开发团队 ..? |
 |
noteditJun 26, 2013
14
我比较赞同你们的leader 把架构搞复杂了 带来的维护成本更高
比如你的lua代码有人维护么 可以很容易的进行单元测试么 可以很容易的继续集成么 |
 |
mudoneJun 26, 2013
15
在一个组织里做东西，leader更多的考虑到如果你离开后这部分的东西如何处理和维护。
|
|
minJun 26, 2013
16
facebook里已经有hhvm教派了，教义完备信众一大帮，自成体系,和php信的不是一个神
你们公司都信默罕默德的，就你一个哭着喊着要说猪肉挺好吃，让大家一起吃，能有好结果么你 ^_^ |
|
18
|
 |
zhangxiaoJun 26, 2013
19
@qiongqi 你把tests写好再拿去劝x爷。还可以把你写的部分部署成替补或者灾备，万一性能出问题了能立刻顶上也不错，但是估计你需要自己花时间去保证这部分的更新了...
|
|
20
@zhangxiao 更新不费劲，没有什么新的feature了，就是老的一大堆，也没人负责，删掉的话就跳了一堆人不同意。。现在都是我自己有时间的话，写着玩。。最终能成型的话，就放github上
晓哥在那边滋润不？据说那里一年有半年放假？ |
 |
cloudzhouJun 26, 2013
22
看情况，如果我是 leader 的话，不到遇到性能问题，或者准备架构更新，是很难支持异构的。异构遇到的问题只有后来才深刻体会。
|
 |
huaiyinhouAug 18, 2013 via Android
23
@qiongqi 选这个主要还是与业务系统有关与已有架构。
|
Select Language