在邮件组里看到有人问能不能把多个hiphop-php编译后的程序跑在同一个端口上，想想也是合理的要求。如果一个服务器上跑了多个站点，那肯定都得用80端口，当大家共同租用服务器的时候，这个需求更为强烈。当时我所想到的解决办法是在前面搭个nginx之类的做代理，实际编译后的程序跑在别的端口，然后没过几天就看到了这份wiki - Using nginx as front server to HipHop。
简单的nginx配置示例
/etc/nginx/conf.d/ooso.conf:
PLAIN TEXT
不得不说，现在安装hiphop-php实在是太麻烦了，如果有rpm包一次搞定那该多好？就说周边那些零散的依赖库，也有不少安装比较繁琐的硬骨头。
Centos用户的好消息
Update: 在centos 64位机上完全通过rpm安装hiphop-php的步骤也已经提供了。
在邮件组上看到有人提供了centos下安装hiphop相关的rpm列表，把这些rpm装好，再按照wiki上专心编译hiphop即可。也许再过一阵，就会有人直接提供hiphop的rpm包，那就彻底方便了。
昨天facebook在github上发布了hiphop-php的源代码。之前听说这玩意能把php代码翻译成c++代码，然后带来巨大的性能提升，所以第一时间编译了一份hiphop-php。
我的机器环境是
Centos 5.3 x86_64
继上次解决memcache连接慢问题以来，好长一段时间没在这个问题上翻过跟头。这一次我又在生产环境观察到php和memcache的连接时间经常会在50ms以上。
作为一个cache，占用了这么长的执行时间，天理何在？
实际的运行环境如下：
xhprof是facebook开源出来的一个php性能测试工具，也可以称之为profile工具，这个词不知道怎么翻译才比较达意。跟之前一直使用的xdebug相比，有很多类似之处。以前对xdebug有一些记录还可以供参考，但是它的缺点是对性能影响太大，即便是开启了profiler_enable_trigger参数，用在生产环境中也是惨不忍睹，cpu立刻就飙到high。
而xhprof就显得很轻量，是否记录profile可以由程序控制，因此，用在生产环境中也就成为一种可能。在它的文档上可以看到这样一种用法：
在php开发中，开启memcache的数据压缩存储是一件很简单的事情。在多数情况下，压缩数据不仅不会降低程序的执行效率，反倒会因为网络传输的开销降低，带来速度提升。看看最常用的Memcache::set方法:
bool Memcache::set ( string $key , mixed $var [, int $flag [, int $expire ]] )
在这个方法中，将$flag设置为MEMCACHE_COMPRESSED即可启用memcache压缩存储。
这样做有什么弊端？
在apache的环境下，rewrite还真是生活之友啊，时不时就得用上。前些日子有个需求，要将url重新转一转。
什么情况？
原来的url
http://www.xxx.com/demo/oldpage.php?param1=1¶m2=2
twitter最近将ruby实现的消息队列服务器starling开源了，这是一个支持memcache协议的轻量级持久化服务器，因此使用php/perl/ruby/java等多种客户端都没问题，可以将较慢的处理逻辑通过消息队列放在后台处理，同时也支持多点分布式处理。周末找了个闲置的centos 5机器搭了一套starling试用，配合php的memcache扩展测试一番，有点意思。
starling安装步骤
centos默认不带ruby，得重新装，以下安装步骤都是以root身份跑的。