php实现的thrift socket server
这些天用php写了个thrift的socket server，因为原来thrift的源码里php部分只有基于apache的服务器端代码，再加上前些日子看到php也能直接使用libevent构建web服务器，所以才会想到写这个玩玩。
php-thrift-server源码
代码直接从apache的thrift项目clone过来，托管在github上：
http://github.com/volca/thrift
当前文章被分类为：php
php的filter扩展小技巧
做为一个合格的web开发人员，一定会牢记一个原则——永远不能相信用户输入的数据，行走江湖，安全第一是很重要的。用户通过表单或url传过来的数据，一定要仔细检查过了，才往后台数据库里存进去。在一个成熟的开发团队里，贯彻这个原则不成问题；但是如果在一个新人老手混搭的小team里，很容易就忽视了这个问题，那么各种安全漏洞比如跨站攻击，sql注入等等真是防不胜防。
实际上，用php 5自带的filter扩展能够较好的解决这个问题。我在从前的blog里记录了filter扩展的常规用法——直接利用filter来校验数据，这样有不少额外的代码量，所以我得介绍一个比较偷懒的办法——自动对所有输入变量进行过滤，这只需要对php.ini增加一行配置，然后重启apache或fastcgi让php配置生效。
关于“facebook的memcached实战”小记
上周挤到QCon的会场里，听了两场 —— Facebook的Memcached实战，以及Twitter 的可伸缩性数据架构。当时对facebook超大规模使用memcached印象很深刻，只可惜到现在也没见到这个的ppt。平时用php比较多，因此听闻同样使着php的facebook讲memcached，有些小小的感触，记录下来。
更高效的序列化函数
php有两个memcache扩展，默认都是使用php自带的序列化函数serialize来存储数组或对象。但是serialize最为人诟病的就是速度慢，序列化之后占用空间大。由于facebook已经在memcached里保存了200T字节的数据，因此序列化函数即便作出的百分之一的优化对它来说都是个不小的收益。他们发粪涂墙在thrift的binary协议基础上搞出了一个fb_serialize，据称这个序列化方法能快上3倍，快倒算了，还能节省30%空间， 200T字节的数据能节省出30%，简直就是传说中的银弹啊，这让php官方的开发人员们情何以堪？
关于改善xhprof使用情况的设想
自从去年将xhprof用在生产环境以来，对生产环境的程序调试，性能优化都带来很多便利。但是在使用过程中，还是有一些细节需要改善。
问题
试着开源LiteCloud项目
所谓LiteCloud，无非就是前些天提到的LightCloud的php版本实现。这个和原来的python版本有一些区别，会造成不兼容，如下：
把Consistent Hashing算法换成了ketama，在pecl的memcached扩展里有简单方法可以实现，效率比单纯的php好很多，能快个10倍吧。没有重复造轮子，因此我很是得意。
使用nginx做为hiphop-php的前端服务器
在邮件组里看到有人问能不能把多个hiphop-php编译后的程序跑在同一个端口上，想想也是合理的要求。如果一个服务器上跑了多个站点，那肯定都得用80端口，当大家共同租用服务器的时候，这个需求更为强烈。当时我所想到的解决办法是在前面搭个nginx之类的做代理，实际编译后的程序跑在别的端口，然后没过几天就看到了这份wiki - Using nginx as front server to HipHop。
简单的nginx配置示例
/etc/nginx/conf.d/ooso.conf:
PLAIN TEXT
快速安装hiphop-php的捷径
不得不说，现在安装hiphop-php实在是太麻烦了，如果有rpm包一次搞定那该多好？就说周边那些零散的依赖库，也有不少安装比较繁琐的硬骨头。
Centos用户的好消息
Update: 在centos 64位机上完全通过rpm安装hiphop-php的步骤也已经提供了。
在邮件组上看到有人提供了centos下安装hiphop相关的rpm列表，把这些rpm装好，再按照wiki上专心编译hiphop即可。也许再过一阵，就会有人直接提供hiphop的rpm包，那就彻底方便了。
初次体验hiphop-php
昨天facebook在github上发布了hiphop-php的源代码。之前听说这玩意能把php代码翻译成c++代码，然后带来巨大的性能提升，所以第一时间编译了一份hiphop-php。
我的机器环境是
Centos 5.3 x86_64