我用openresty重构可几个访问量比较大的接口，结果被否定了，被认为是异化了架构
qiongqi · 2013-05-29 23:04:01 +08:00 via Android · 11495 次点击这是一个创建于 4231 天前的主题，其中的信息可能已经有所发展或是发生改变。
3个接口都是内部api使用的，访问量在5000rps左右，公司的业务处理和api层都是用PHP做的，我觉得这3个接口（一个读db的，一个读redis的，一个curl到平台服务的）逻辑简单，没必要用php来做，直接用openresty做好了，效率肯定只高不低，结果在提交之后被大头否定了，然后举了hiphop的例子，认为如果想快，就去让hiphop支持我们的代码就好了。。唉:-(
第 1 条附言 · 2013-06-16 11:19:15 +08:00
昨天在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了？
 |
1
harryyyt 2013-05-29 23:10:35 +08:00
遇到和LZ类似的问题，比较了Openresty，Node.Js和PHP三种方案，还是用Openresty的ngx_lua实现最快。也考虑过用hiphop，不过这玩意捣腾了半天还是没弄起来...我想既然是优化性能就用性能最佳的方案好了，不过上头可能是基于会lua的人不多的原因考虑
|
 |
2
rebellion 2013-05-29 23:13:29 +08:00
楼主的头像好幸福的样子
|
 |
3
qiongqi OP @harryyyt 我们代码里用了namespace，貌似hiphop不支持这个。。头的意思是自己改hiptop。。我觉得有把hiptop改好的能力，n个openresty都学会了
|
 |
5
lookhi 2013-06-16 12:12:12 +08:00
hiphop facebook?
|
 |
7
raincious 2013-06-16 13:32:06 +08:00
不用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-06-23 21:53:20 +08:00
确实会破坏架构，领导也要考虑测试、发布、维护、招聘的成本。
|
 |
10
min 2013-06-25 21:05:52 +08:00
妥妥的异端啊，搁早几百年绑十字架上一把火就把lz你给点了 ^_^
|
|
11
qiongqi OP @tedeyang 确实会有这个问题，但是我还是不觉得当摊子大了以后，还是都依靠php来做，看看facebook，现在估计想迁个接口都迁不动了。
|
|
12
qiongqi OP @min 那我岂不是跟布鲁诺一个层次了。。历史书上还能留个名
hhvm也很极端啊，用hhvm，岂不是抛弃整个现在php的社区 |
 |
13
Sunyanzi 2013-06-26 12:46:20 +08:00
leader 人很好啊 ... 他自己觉得是异端但是至少他会看数据然后屈服于更好的技术 ...
另外说 hiphop 远比各种 OPCACHE 提升得要多 ... 因为一个是重编译一个只是缓存 ... 说来这得是多大的公司才会自己组团研究 HHVM 啊 ... 至少八十人的开发团队 ..? |
 |
14
notedit 2013-06-26 13:00:49 +08:00
我比较赞同你们的leader 把架构搞复杂了 带来的维护成本更高
比如你的lua代码有人维护么 可以很容易的进行单元测试么 可以很容易的继续集成么 |
 |
15
mudone 2013-06-26 13:28:05 +08:00
在一个组织里做东西，leader更多的考虑到如果你离开后这部分的东西如何处理和维护。
|
|
16
min 2013-06-26 14:00:34 +08:00
facebook里已经有hhvm教派了，教义完备信众一大帮，自成体系,和php信的不是一个神
你们公司都信默罕默德的，就你一个哭着喊着要说猪肉挺好吃，让大家一起吃，能有好结果么你 ^_^ |
|
17
qiongqi OP @Sunyanzi leader人不错的。我们部门没有那么多人，只要有同事去测试hhvm的性能了，之前说的修改hiphop也就是leader随口一说
|
|
18
qiongqi OP |
 |
19
zhangxiao 2013-06-26 15:07:25 +08:00
@qiongqi 你把tests写好再拿去劝x爷。还可以把你写的部分部署成替补或者灾备，万一性能出问题了能立刻顶上也不错，但是估计你需要自己花时间去保证这部分的更新了...
|
|
20
qiongqi OP @zhangxiao 更新不费劲，没有什么新的feature了，就是老的一大堆，也没人负责，删掉的话就跳了一堆人不同意。。现在都是我自己有时间的话，写着玩。。最终能成型的话，就放github上
晓哥在那边滋润不？据说那里一年有半年放假？ |
 |
22
cloudzhou 2013-06-26 18:02:23 +08:00
看情况，如果我是 leader 的话，不到遇到性能问题，或者准备架构更新，是很难支持异构的。异构遇到的问题只有后来才深刻体会。
|
 |
23
huaiyinhou 2013-08-18 01:05:14 +08:00 via Android
@qiongqi 选这个主要还是与业务系统有关与已有架构。
|
Select Language