上次翻译了一篇外国blog讲了下hiphop实际应用中可能遇到的状况和一些问题,请看这里

在翻译完之后我觉得这篇文章有很多地方说得很贴切,而且在我的实际研究过程中也确实遇到了很多问题

首先,编译的问题:一个大的项目的编译绝对是个问题,这个问题还包含了很多个小的问题,我罗列下。
时间问题,一个大的软件库,编译的时间绝对是很可怕的,特别是机器不好的状况下,每次你需要做改动,或者需要出版本的时候,一个细小的改动绝对会花上你很多的编译时间,甚至这还不是你工作时间中的重点,这点比较过分,简单来说这些时间可以算在浪费的范畴之类。
编译错误问题,在php开发的过程中可能你永远不会遇到这么多错误在一个地方集中让你解决。在php里,可能在某几块开发过程中你会发现你遇到了某些错误,但是绝对不会让你一次性遇到那么多错误(我尝试了编译了下production,结果绝对让人崩溃)。当然这个问题我们也需要辩证地面对,错误问题列给你绝对比隐藏起来不让你发现要好,但是这种错误的呈现/提交形式可能就比较呆板了,在某些需要灵活性的场合就有点拘束。

其次,开发流程问题:php的好处其实就在于开发流程简单,开发、打开页面测试,简单来说就是这两步。但是如果使用hiphop的话,需要在整个发布、测试流程中嵌入一个编译、部署的过程,而且这个部署还不是简单的文件拷贝这么简单。这使得开发的过程变得相对简单php冗长繁琐太多太多。

最后,性能问题:虽然hiphop号称能减少50%CPU的使用(我没看到过真实项目的实际测试数据),但是在一个很普遍的项目下,情况是这样的:web服务器并不是问题,它们可以很容易地通过扩展服务器台数来解决性能问题,相比来说db服务器的扩展要难上很多很多。所以我们经常说一般服务器的性能瓶颈在db这边,而不再web这边,就是这么一回事。那么很简单能看出,在这样一个大的环境背景上来说hiphop就显得并不是这么重要了。

简单来个结论:在目前的项目背景下来说,用hiphop还是有点得不偿失的感觉,所以暂时把它的研究压下来,等待更好的时机的到来再开始。比如说facebook把hiphop的稳定版本release出来,或者服务器的cost压力已经远远超出项目预期了。

我目前对hiphop研究的进度是安装、初步的示例使用都没有问题了,并且简单的编译和hphpi服务器的启动使用也没有问题了。
接下去的研究项目是:
进一步的编译配置项使用(使用编译配置文件)
大项目codebase的成功编译
编译的脚本自动化
hphpi服务器的进一步启动配置及优化
hphpi服务器静态文件(图片、js、css)的访问服务器
nginx服务器前端代理