我用openresty重构可几个访问量比较大的接口，结果被否定了，被认为是异化了架构

[qiongqi]

3个接口都是内部api使用的，访问量在5000rps左右，公司的业务处理和api层都是用PHP做的，我觉得这3个接口（一个读db的，一个读redis的，一个curl到平台服务的）逻辑简单，没必要用php来做，直接用openresty做好了，效率肯定只高不低，结果在提交之后被大头否定了，然后举了hiphop的例子，认为如果想快，就去让hiphop支持我们的代码就好了。。唉:-(

[harryyyt]

遇到和LZ类似的问题，比较了Openresty，Node.Js和PHP三种方案，还是用Openresty的ngx_lua实现最快。也考虑过用hiphop，不过这玩意捣腾了半天还是没弄起来...我想既然是优化性能就用性能最佳的方案好了，不过上头可能是基于会lua的人不多的原因考虑

[rebellion]

楼主的头像好幸福的样子

[qiongqi]

@harryyyt 我们代码里用了namespace，貌似hiphop不支持这个。。头的意思是自己改hiptop。。我觉得有把hiptop改好的能力，n个openresty都学会了

[qiongqi]

@rebellion 还好吧，我和我gf都是随遇而安型的，不求上进，所以比较容易满足

[lookhi]

hiphop facebook?

[qiongqi]

@lookhi 是facebook开源的hiphop，最新的应该是hhvm，应该是支持PHP 5.3了

[raincious]

不用hiphop那么麻烦。

可以等PHP 5.5上线之后+opCache一起用，很轻松就能优化到10毫秒左右。

[qiongqi]

@raincious PHP 5.5是等不到了，已经有同事在弄hhvm了。
其实我对hhvm一直没有一个系统的认识，google也没有找到hhvm跟apc，eAccelerator的性能对比。
感觉hhvm提高的有限，已经是跟apc一个级别的。
还是跟openresty这种杀手级的应用不在同一个level上。

是不是，PHP就不太适合做访问量很大的api使用？

[tedeyang]

确实会破坏架构，领导也要考虑测试、发布、维护、招聘的成本。

[min]

妥妥的异端啊，搁早几百年绑十字架上一把火就把lz你给点了 ^_^

[qiongqi]

@tedeyang 确实会有这个问题，但是我还是不觉得当摊子大了以后，还是都依靠php来做，看看facebook，现在估计想迁个接口都迁不动了。

[qiongqi]

@min 那我岂不是跟布鲁诺一个层次了。。历史书上还能留个名
hhvm也很极端啊，用hhvm，岂不是抛弃整个现在php的社区

[Sunyanzi]

leader 人很好啊 ... 他自己觉得是异端但是至少他会看数据然后屈服于更好的技术 ...

另外说 hiphop 远比各种 OPCACHE 提升得要多 ... 因为一个是重编译一个只是缓存 ...

说来这得是多大的公司才会自己组团研究 HHVM 啊 ... 至少八十人的开发团队 ..?

[notedit]

我比较赞同你们的leader 把架构搞复杂了 带来的维护成本更高

比如你的lua代码有人维护么 可以很容易的进行单元测试么 可以很容易的继续集成么

[mudone]

在一个组织里做东西，leader更多的考虑到如果你离开后这部分的东西如何处理和维护。

[min]

facebook里已经有hhvm教派了，教义完备信众一大帮，自成体系,和php信的不是一个神

你们公司都信默罕默德的，就你一个哭着喊着要说猪肉挺好吃，让大家一起吃，能有好结果么你 ^_^

[qiongqi]

@Sunyanzi leader人不错的。我们部门没有那么多人，只要有同事去测试hhvm的性能了，之前说的修改hiphop也就是leader随口一说

[qiongqi]

@notedit @mudone 这个我能理解，就是觉得既然能有用hhvm的魄力，接受一门新的语言也应该不是问题。我觉得从php到openresty几乎是零学习成本。代理的维护，测试也是需要人慢慢做的，php刚上的时候，也是没有phpunit的啊

[zhangxiao]

@qiongqi 你把tests写好再拿去劝x爷。还可以把你写的部分部署成替补或者灾备，万一性能出问题了能立刻顶上也不错，但是估计你需要自己花时间去保证这部分的更新了...

[qiongqi]

@zhangxiao 更新不费劲，没有什么新的feature了，就是老的一大堆，也没人负责，删掉的话就跳了一堆人不同意。。现在都是我自己有时间的话，写着玩。。最终能成型的话，就放github上
晓哥在那边滋润不？据说那里一年有半年放假？