代码在github上：https://github.com/volca/AsyncHttpClient

使用示例

如下，在request的时候能够定义请求完成之后的callback函数。

<?php
$base = event_base_new();

$uri = "http://www.baidu.com/";
$config = array(
    'eventbase' => $base
);

for($i = 0; $i < 10; $i++) {
    $client = new AsyncHttpClient($uri, $config);
    $client->request(function($result) {
        echo "Result len:";
        echo strlen($result['response']);
        // parse response with Zend_Http_Response
        $response = Zend_Http_Response::fromString($result['response']);
        echo $response->getBody();
        echo "\n";
    });
}

event_base_loop($base);
echo "done\n";

目前的实现比较初级，只做了get方法的封装，如果需要http上传或者post，还需要另外实现。另外这个类也需要php的libevent扩展。

Update 2011.11.17

将这个类修改为继承自Zend_Http_Client，这样我可以少写一些代码，顺带也实现了文件http上传以及post（未经测试）,代码中的使用示例也已经更新。

• phpDaemon — 一个异步的服务器端开发框架.
• tail – 用php实现类似unix下的tail命令行
• ZeroMQ + libevent in PHP – 用php和ZeroMQ实现的一个事件驱动服务器端

我所想到的一个比较实用的使用场景是，在页面中利用libevent请求多个http接口来获得数据。若是在从前，一个可行的办法是利用curl_multi_exec来同时请求好几个接口，但是这个办法需要用一个do … while循环来完成请求，很是坑爹。那么看看采用libevent的例子:

代码实例 http.php

<?php
$base_fd = event_base_new();
$times = 0;
$limit = 10;
$index = array();

function httpGet($host, $base_fd) {
    global $index;

    $fd = stream_socket_client("$host:80", $errno, $errstr, 3, STREAM_CLIENT_ASYNC_CONNECT | STREAM_CLIENT_CONNECT);
    $index[$fd] = 0;
    $event_fd = event_new();
    event_set($event_fd, $fd, EV_WRITE | EV_PERSIST, function($fd, $events, $arg) use($host) {
        global $times, $limit, $index;

        if(!$index[$fd]) {
            $index[$fd] = 1;
            $out = "GET / HTTP/1.1\r\n";
            $out .= "Host: $host\r\n";
            $out .= "Connection: Close\r\n\r\n";
            fwrite($fd, $out);
        } else {
            echo fread($fd, 4096);
            if(feof($fd)) {
                fclose($fd);
                $times++;
                echo "done\n";

                if($times == $limit - 1) {
                    event_base_loopexit($arg[1]);
                }
            }
        }
    }, array($event_fd, $base_fd));

    event_base_set($event_fd, $base_fd);
    event_add($event_fd);
}

for($i = 0; $i < $limit; $i++) {
    echo "$i\n";
    httpGet($argv[1], $base_fd);
        //echo file_get_contents("http://$argv[1]");
}

event_base_loop($base_fd);
?>

为了省事，这个php脚本仅仅是重复抓取一个网页5次，并且回调的逻辑我没怎么做处理，仅仅是echo出来而已，可以通过下面命令行来运行这个例子:

php http.php "www.baidu.com"

代码中的http_get($argv[1])这行虽然是靠一个命令行顺序执行，但是不会阻塞后面的代码，直接就进行下一次请求了。而且我们看看回调方法部分是不是很像用javascript调用ajax写的回调方法？这都是php 5.3中闭包的功劳。

event_set($event_fd, $fd, EV_WRITE | EV_PERSIST, function($fd, $events, $arg) {
    //回调方法，后续处理随意
    echo fread($fd, 4096);
    if(feof($fd)) {
        fclose($fd);
	event_base_loopexit($arg[1]);
	echo "done";
    }
}, array($event_fd, $base_fd));

想到更多

在mysqlnd，memcached…这些php扩展中，都已经有delay回调的实现，如果能好好利用，对性能提升岂不是有莫大的帮助？或者在libevent扩展的基础上，实现一个事件驱动的开发框架，也是可行的。

Update 2011.11.10

在这个代码的基础上实现了一个异步http请求的客户端

Update 2011.10.28

event_base_loop是会阻塞后续代码执行的，所以我调整了示例代码，使用同一个event_base，并且用stream_socket_client来进行异步连接，另外在/etc/hosts指定域名的ip会对执行速度有帮助。

安装pman

使用传说中的pear来安装pman

sudo pear install doc.php.net/pman

如果pear版本比较老，需要先升级pear才可以继续

sudo pear upgrade pear

pman使用方法

pman的使用方法很傻瓜，比如我们想查看strlen的帮助信息:

pman strlen

帮助文本的内容是彩色的，能和chm版本的php帮助文档媲美。pman的详细使用帮助如下

#pman --help
man, version 1.6c

usage: man [-adfhktwW] [section] [-M path] [-P pager] [-S list]
	[-m system] [-p string] name ...

  a : find all matching entries
  c : do not use cat file
  d : print gobs of debugging information
  D : as for -d, but also display the pages
  f : same as whatis(1)
  h : print this help message
  k : same as apropos(1)
  K : search for a string in all pages
  t : use troff to format pages for printing
  w : print location of man page(s) that would be displayed
      (if no name given: print directories that would be searched)
  W : as for -w, but display filenames only

  C file   : use `file' as configuration file
  M path   : set search path for manual pages to `path'
  P pager  : use program `pager' to display pages
  S list   : colon separated section list
  m system : search for alternate system's man pages
  p string : string tells which preprocessors to run
               e - [n]eqn(1)   p - pic(1)    t - tbl(1)
               g - grap(1)     r - refer(1)  v - vgrind(1)

还有一个好处是在vim里查看php帮助信息更方便了，结合完美

:!pman strlen

在远程服务器的设置

假定你需要部署的代码在/var/www/yoursite

cd /var/www/yoursite
git init .
git config receive.denyCurrentBranch ignore
git config --bool receive.denyNonFastForwards false
cd .git/hooks
wget http://utsl.gen.nz/git/post-update
chmod +x post-update

在本地git库中新增配置

[remote "prod"]
        url = your-ssh-username@your-host:/var/www/yoursite/

这样就算设置完成了。

如果你想把本地的代码推送到远程服务器，下面简单的步骤就可以做到

git pull
git push prod

注意事项

如果远程服务器上git的配置目录.git暴露在外部可访问的位置，请在web服务器上设置这个目录不可见。

伪造跨站请求比较难以防范，而且危害巨大，攻击者可以通过这种方式恶作剧，发spam信息，删除数据等等。这种攻击常见的表现形式有：

• 伪造链接，引诱用户点击，或是让用户在不知情的情况下访问
• 伪造表单，引诱用户提交。表单可以是隐藏的，用图片或链接的形式伪装。

比较常见而且也很廉价的防范手段是在所有可能涉及用户写操作的表单中加入一个随机且变换频繁的字符串，然后在处理表单的时候对这个字符串进行检查。这个随机字符串如果和当前用户身份相关联的话，那么攻击者伪造请求会比较麻烦。

yahoo对付伪造跨站请求的办法是在表单里加入一个叫.crumb的随机串；而facebook也有类似的解决办法，它的表单里常常会有post_form_id和fb_dtsg。

随机串代码实现

咱们按照这个思路，山寨一个crumb的实现，代码如下：

<?php
class Crumb {                                                                                                  

    CONST SALT = "your-secret-salt";                                                         

    static $ttl = 7200;                                                                                           

    static public function challenge($data) {
        return hash_hmac('md5', $data, self::SALT);
    }                                                                                                             

    static public function issueCrumb($uid, $action = -1) {
        $i = ceil(time() / self::$ttl);
        return substr(self::challenge($i . $action . $uid), -12, 10);
    }                                                                                                             

    static public function verifyCrumb($uid, $crumb, $action = -1) {
        $i = ceil(time() / self::$ttl);                                                                           

        if(substr(self::challenge($i . $action . $uid), -12, 10) == $crumb ||
            substr(self::challenge(($i - 1) . $action . $uid), -12, 10) == $crumb)
            return true;                                                                                          

        return false;
    }                                                                                                             

}

代码中的$uid表示用户唯一标识，而$ttl表示这个随机串的有效时间。

应用示例

构造表单
在表单中插入一个隐藏的随机串crumb

<form method="post" action="demo.php">
<input type="hidden" name="crumb" value="<?php echo Crumb::issueCrumb($uid)?>">
<input type="text" name="content">
<input type="submit">
</form>

处理表单 demo.php
对crumb进行检查

<?php
if(Crumb::verifyCrumb($uid, $_POST['crumb'])) {
    //按照正常流程处理表单
} else {
    //crumb校验失败，错误提示流程
}

php-thrift-server源码

代码直接从apache的thrift项目clone过来，托管在github上：

http://github.com/volca/thrift

新增或改动的代码如下:

lib/php/
`-- src
    |-- server
    |   |-- TNonblockingServer.php
    |   `-- TServer.php
    `-- transport
        |-- TNonblockingServerSocket.php
        |-- TNonblockingSocket.php
        |-- TServerSocket.php
        |-- TServerTransport.php
test/php
|-- TestClient.php
|-- TestNonblockingServer.php

使用示例

获取thrift的源码，并编译出thrift工具，编译过程请搜索

git clone git://github.com/volca/thrift.git

安装php,以及apc, libevent扩展:

pecl install apc
#需要先libevent-devel之类的包包
pecl install libevent

运行php的socket服务器，我直接从thrift的test代码中修改了一个独立运行的php server，见thrift/test/php/TestNonblockingServer.php，这里也包含一个测试业务代码的实现。

cd thrift/test/php
#用thrift命令行工具生成php的测试类库
make
#启动thrift服务，会监听本机的9090端口
php TestNonblockingServer.php

客户端的代码也一并提供，对各种数据类型比如int, float, string, list等等进行测试。

php TestClient.php

性能测试

apache + php的测试结果

testVoid() = void
testString("Test") = "Test"
testByte(1) = 1
testI32(-1) = -1
testI64(-34359738368) = -34359738368
testDouble(-852.234234234) = -852.234234234
testStruct({"Zero", 1, -3, -5}) = {"Zero", 1, -3, -5}
testNest({1, {"Zero", 1, -3, -5}), 5} = {1, {"Zero", 1, -3, -5}, 5}
testMap({0 => -10, 1 => -9, 2 => -8, 3 => -7, 4 => -6}) = {0 => -10, 1 => -9, 2 => -8, 3 => -7, 4 => -6}
testSet({-2, -1, 0, 1, 2}) = {1, 1, 1, 1, 1}
testList({-2, -1, 0, 1, 2}) = {-2, -1, 0, 1, 2}
testEnum(ONE) = 1
testEnum(TWO) = 2
testEnum(THREE) = 3
testEnum(FIVE) = 5
testEnum(EIGHT) = 8
testTypedef(309858235082523) = 309858235082523
Total time: 41 ms

php + libevent的socket server测试结果

testVoid() = void
testString("Test") = "Test"
testByte(1) = 1
testI32(-1) = -1
testI64(-34359738368) = -34359738368
testDouble(-852.234234234) = -852.234234234
testStruct({"Zero", 1, -3, -5}) = {"Zero", 1, -3, -5}
testNest({1, {"Zero", 1, -3, -5}), 5} = {1, {"Zero", 1, -3, -5}, 5}
testMap({0 => -10, 1 => -9, 2 => -8, 3 => -7, 4 => -6}) = {0 => -10, 1 => -9, 2 => -8, 3 => -7, 4 => -6}
testSet({-2, -1, 0, 1, 2}) = {1, 1, 1, 1, 1}
testList({-2, -1, 0, 1, 2}) = {-2, -1, 0, 1, 2}
testEnum(ONE) = 1
testEnum(TWO) = 2
testEnum(THREE) = 3
testEnum(FIVE) = 5
testEnum(EIGHT) = 8
testTypedef(309858235082523) = 309858235082523
Total time: 8 ms

这个测试中，没有耗时很长的请求，处理逻辑完全一样，php socket server耗时仅为apache + php的五分之一。

thrift是什么？

thrift流传的似乎不是太广泛，而且有被别的技术替代的趋势，所以下面还是引用一下别的文章的介绍：

Thrift由一个软件库和一系列的代码生成工具组成，由 Facebook开发。目的是为了加快软件开发和实现高效和可扩展的后台服务。主要目标是不同程序开语言之间实现高效和可靠的通信，这需要将不同语言之间抽象出一个通用层，然后由不同语言来实现这个通用层。在这里要特别指出的是，Thrift允许开发人员定义数据类型和服务接口（定义在一个中性语言文件里），并通过这个文件生成构建RPC客户端和服务端所需的代码。

简单分析其机理，Thrift就是实现C/S模式，通过代码生成工具将接口定义文件生成服务器端和客户端代码（可以为不同语言），从而实现服务端和客户端跨语言的支持。

Thrift可以分为传输层和协议层：

传输层定义了数据的传输方式，可以为TCP/IP传输，内存共享或者文件共享等形式；
协议层定义了数据的传输格式，可以为二进制流或者XML等形式。
当服务器端使用socket协议时，可以用simple|thread-pool|threaded|nonblocking等方式运行，从而获得更好的性能。

实际上，用php 5自带的filter扩展能够较好的解决这个问题。我在从前的blog里记录了filter扩展的常规用法——直接利用filter来校验数据，这样有不少额外的代码量，所以我得介绍一个比较偷懒的办法——自动对所有输入变量进行过滤，这只需要对php.ini增加一行配置，然后重启apache或fastcgi让php配置生效。

filter.default=”special_chars”

开启了这项配置后，会自动使用filter_input方法对$_GET, $_POST, $_COOKIE, $_REQUEST以及$_SERVER变量进行过滤转义。配置中special_chars是常量FILTER_SANITIZE_SPECIAL_CHARS的缩写，它能自动转义大部分危险字符例如： '"<>。而php手册对它的解释是：

HTML-escape ‘”<>& and characters with ASCII value less than 32, optionally strip or encode other special characters.

在这个情况下，新人们写出这样的代码我也不会太担心:

$foo = $_GET['foo'];
echo $foo;

在部分场合，我们可能还是需要未转义的变量，比如某个ajax接受的参数是一段json串，用这段代码即可获得原始数据：

$foo = filter_input (INPUT_GET, 'foo',  FILTER_UNSAFE_RAW);

fitler扩展与yahoo使用的yiv如出一辙，印象里似乎就是yahoo对yiv做了些修改贡献给php社区，但是暂时没找到出处。

更高效的序列化函数

php有两个memcache扩展，默认都是使用php自带的序列化函数serialize来存储数组或对象。但是serialize最为人诟病的就是速度慢，序列化之后占用空间大。由于facebook已经在memcached里保存了200T字节的数据，因此序列化函数即便作出的百分之一的优化对它来说都是个不小的收益。他们发粪涂墙在thrift的binary协议基础上搞出了一个fb_serialize，据称这个序列化方法能快上3倍，快倒算了，还能节省30%空间， 200T字节的数据能节省出30%，简直就是传说中的银弹啊，这让php官方的开发人员们情何以堪？

facebook目前已经开源了thrift，其中自带了一个thrift协议的php扩展，但是这些代码里没有找到传说中的fb_serialize，我倒是从最近他们放出来hiphop-php里找到了这部分代码，哪位大侠去扒拉扒拉弄出来做成php扩展造福广大群众？

作为备选方案，我推荐igbinary，这也是一个binary的序列化方法。在上次的测试结果中，它甚至能节约50%的存储空间，速度也是稳超php原生的序列化方法，搞不好facebook换了这个序列化方法能省下更多的内存来？

节约每个item的存储空间有什么好处？我个人认为一个是省钱，另外一个就是能够带来速度上的提升。我们平常碰到稍大一点的item都得用gzip压的妥妥贴贴的才送到memcached里，网络传输的开销小了，这是实实在在的性能提升。何乐而不为？

mcproxy

mcproxy = memcached + proxy。facebook的机房遍布各洲，利用mcproxy来进行跨机房的同步或分发，全球制霸，指着太阳就能等到那天了。一般的互联网企业还真用不上这玩意，规模还没上去的时候，这些乱七八糟的只会拖后腿。facebook还没开源mcproxy，但是我找到两个替代品：

• memagent is a simple but useful proxy program for memcached servers.
• moxi = memcached + integrated proxy

从项目描述来看，moxi最接近facebook介绍的mcproxy，成熟度也比较高。

数据的一致性

Marc Kwiatkowski在会场上用大篇幅的ppt和大量的动画来阐述这个问题，他们用了很多额外的手段来解决在跨机房情况下因为延时问题造成的脏数据。这一段看着挺晕，但是我们联想到facebook用到的多级cache技术: 本地全局变量 + apc + memcache，不难理解这样做颇有些道理，这相当于用memcache实现了一个版本控制系统。

我还是很晕这段ppt。

问题

• xhprof的profile日志直接以文件形式保存在生产服务器上，需要定时清理，或者收集起来移动到查看日志的工具机上。
• 由于xhprof生成的profile是一个大数组，所以保存到文件时使用了标准的php serialize，日志文件偏大，一个不留神就容易占用很多服务器磁盘空间。
• 查看日志列表时，一个个点开查看比较费劲。

针对这几个问题，我有一些小小的设想。

日志存放

部署一个中央日志服务器，采用facebook的scribe来收集日志。生产环境的服务器产生的xhprof日志，都写入到scribe的客户端，由客户端自动同步到中央日志服务器的scribe上，不占用本地的存储空间。在代码上的改动也比较小，只要基于iXHProfRuns接口实现一个XhprofRuns类，调整save_run方法的存储方式即可。

更换序列化方法

xhprof默认是将profile信息用php原生的序列化方法处理后进行保存，而我在前两天比较过igbinary vs serialize vs json_encode的性能和占用字节数，这个测试里igbinary在各方面都有一定优势，尤其是占用存储空间会大幅度减小，所以我只要更换序列化方法为igbinary_serialize即可获得改善。

优化列表展示

我已经厌倦挨个查看profile日志的大图，费时费力还没有针对性。所以我现在的做法是，在profile日志的列表中将前1000个日志的总体执行时间直接输出到列表中，并且将执行时间过长的日志用红色粗体标识。做了这个小小的改动之后，当我想要去视察一下运行情况时，就把日志列表中那些红通通的链接点开看看就行了，真正的省时省力。

如何从xhprof日志文件中获取执行时间？简单的代码如下

/**
 * 由xhprof日志获得执行时间
 *
 * @param string $log xhprof日志的文件路径
 * @return int 执行时间
 */
function getSpentTime($log) {
  $profile = unserialize(file_get_contents($log));
  return $profile['main()']['wt'] / 1000;
}

• igbinary_serialize
• igbinary_unserialize

据称可以用它来代替php自带的序列化函数serialize，性能更好，而且占用的字节数也更少。下面我就 igbinary ，serialize ，json_encode三者的性能做了一个简单的测试。

测试

以一个包含1000000个元素的数组做为原始数据，分别以json, serialize, igbinary进行序列化和反向操作。

<?php
ini_set('memory_limit', '512m');
$array = array_fill(0, 1000000, rand(1, 9999));

$start = microtime(true);
$export = json_encode($array);
$end = microtime(true);
$duration = $end - $start;
print('JSON Encode: ' . $duration . PHP_EOL);

$start = microtime(true);
$import = json_decode($export);
$end = microtime(true);
$duration = $end - $start;
print('JSON Decode: ' . $duration . PHP_EOL);

$start = microtime(true);
$export = serialize($array);
$end = microtime(true);
$duration = $end - $start;
print('Serialize: ' . $duration . PHP_EOL);

$start = microtime(true);
$import = unserialize($export);
$end = microtime(true);
$duration = $end - $start;
print('Serialize: ' . $duration . PHP_EOL);

$start = microtime(true);
$export = igbinary_serialize($array);
$end = microtime(true);
$duration = $end - $start;
print('Igbinary Serialize: ' . $duration . PHP_EOL);

$start = microtime(true);
$import = igbinary_unserialize($export);
$end = microtime(true);
$duration = $end - $start;
print('Igbinary Serialize: ' . $duration . PHP_EOL);
?>

测试结果

JSON Encode: 0.084825992584229
JSON Decode: 0.34976410865784
Serialize: 0.38241410255432
Serialize: 7.7904229164124
Igbinary Serialize: 0.046916007995605
Igbinary Serialize: 0.23396801948547

从测试结果来看，速度方面优先级排列为 igbinary > json > serialize。同时我们也可以看到，php原生的serialize在对大对象进行反向操作时，速度真是掉队一大截了。

占用字节数对比

• json: 5000001
• serialize: 15888902
• igbinary: 7868681

在没有中文字符的情况下，json胜出，igbinary次之，serialize又被甩了几条街。

一图顶千言

柱状图越矮小的性能越好

1. 把Consistent Hashing算法换成了ketama，在pecl的memcached扩展里有简单方法可以实现，效率比单纯的php好很多，能快个10倍吧。没有重复造轮子，因此我很是得意。
2. 静态方法调用时，不再支持原来的system参数，原版是用这个来支持多个LiteCloud集群。
3. 第一个版本，利用memcached扩展来读取tokyo tyrant，所以目前仅支持简单的操作比如get, set, delete, increment。其实再努力一下，也可以支持更多的功能，比如redis。
4. 去掉了原版的local_cache功能，我觉得这个功能完全可以放在外面，更灵活。

项目主页

目前托管在github上 —— LiteCloud ，使用git以及github的时间不太长，但是很喜欢，欢迎fork。

使用示例

用静态方法调用:

require 'LiteCloud.php';

$config = array(
    'lookup1_A' => '127.0.0.1:41201',
    'lookup1_B' => '127.0.0.1:51201',

    'storage1_A' => '127.0.0.1:44201',
    'storage1_B' => '127.0.0.1:54201',
);

list($lookupNodes, $storageNodes) = LiteCloud::generateNodes($config);
LiteCloud::init($lookupNodes, $storageNodes);

LiteCloud::set('hello', 'world');
print LiteCloud::get("hello"); # => world
LiteCloud::delete("hello");

print LiteCloud::get("hello"); # => nil

或者采用实例化的方式调用，这种方式能够支持多个LightCloud集群

require 'LiteCloud.php';

$config = array(
    'lookup1_A' => '127.0.0.1:41201',
    'lookup1_B' => '127.0.0.1:51201',

    'storage1_A' => '127.0.0.1:44201',
    'storage1_B' => '127.0.0.1:54201',
);

$cloud = new LiteCloud($config);

$cloud->set('hello', 'world');
print $cloud->get("hello"); # => world
$cloud->delete("hello");

print $cloud->get("hello"); # => nil

看上去和python版本差不多，对吧？

性能测试

这个部分是个重点，之前找到的lightcloud的php版本，性能比原版要慢一个数量级，我可不想在这个地方丢了份。

暂时做了个最简单的性能测试，测试脚本在test目录下。测试条件如下:

1. 底层采用tokyo tyrant作为存储。
2. 单个进程重复操作一万次，比如写一万次hello => world，这个测试条件和python版本完全一致
3. 关闭了local_cache

python版本的测试结果

Finished "Tyrant set" 10000 times in 2.50 sec [4002.0 operations pr.sec]
Finished "Tyrant get" 10000 times in 1.04 sec [9583.7 operations pr.sec]
Finished "Tyrant delete" 10000 times in 7.39 sec [1352.4 operations pr.sec]

LiteCloud的测试结果

Using 1.8229308128357 time to set 10000 values. QPS:5485.67
Using 0.71097207069397 time to get 10000 values. QPS:14065.25
Using 2.1550960540771 time to delete 10000 values. QPS:4640.16

看上去还比较乐观，尤其是delete的性能翻了好几番，几乎要怀疑我在代码实现部分出了差错，在其它方面的表现也是全面超出，因为python版在hash_ring的实现上拖了后腿。

简单的nginx配置示例

/etc/nginx/conf.d/ooso.conf:

server {
        listen *:80;
        server_name *.ooso.net ooso.net;

       location / {
           root   __SERVER_ROOT__;
           index  index.html index.php index.htm;
       }

       location ~ \.php$ {
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header Host www.ooso.net;
        proxy_pass   http://localhost:4247;
      }
}

把hiphop-php编译后的代码跑在4247端口，然后通过nginx把所有对php的请求转发到这个端口，看上去就像我们平常配置的php fastcgi，不是吗？

这样做有什么好处

• 支持负载均衡
• 支持ssl
• 支持gzip压缩
• 用nginx来挡住DoS攻击
• 因为我们的代码需要经过编译才能上线，代码多起来这个时间还真不短，不能像之前单纯的php那样爽快覆盖就完事。把经过编译的最新代码部署在别的端口上，用nginx快速切换，应该是一个比较实际的用法。

额外的技巧

看wiki学到的额外技巧。以下配置段可以防止某些人把别的垃圾域名指向你的主机，结果被搜索引擎认为你用多个域名搞了一堆重复的内容建设，降低搜索权重。

server {
    listen *:80;
    server_name _;

	location / {
		deny all;
	}
}

Centos用户的好消息

Update: 在centos 64位机上完全通过rpm安装hiphop-php的步骤也已经提供了。

在邮件组上看到有人提供了centos下安装hiphop相关的rpm列表，把这些rpm装好，再按照wiki上专心编译hiphop即可。也许再过一阵，就会有人直接提供hiphop的rpm包，那就彻底方便了。

rpm列表

• libicu42-4.2.1-1.x86_64.rpm
• libicu-devel-4.2.1-1.x86_64.rpm
• icu-debuginfo-4.2.1-1.x86_64.rpm
• icu-4.2.1-1.x86_64.rpm
• libcurl4-devel-7.20.0-1.x86_64.rpm
• libcurl4-7.20.0-1.x86_64.rpm
• curl-debuginfo-7.20.0-1.x86_64.rpm
• curl-7.20.0-1.x86_64.rpm
• libevent-1.4.13-1.x86_64.rpm
• boost-devel-1_37_0-1.x86_64.rpm
• boost-debuginfo-1_37_0-1.x86_64.rpm
• boost-1_37_0-1.x86_64.rpm
• cmake-2.6.4-7.el5.x86_64.rpm

Ubuntu 9.10用户的安装指南

Building and Installing on Ubuntu 9.10

看起来还是ubuntu用户最清爽。

注：如果使用了32bit的ubuntu，请使用patch过的hiphop-php进行编译。

Fedora用户的编译步骤

Building HipHop PHP for Fedora 12 on 64 bit and 32 bit Systems

BTW: 目前hiphop-php仅支持64位操作系统。

我的机器环境是

• Centos 5.3 x86_64
• 8G内存
• Intel(R) Xeon(R) CPU E5420 @ 2.50GHz

安装注意事项

编译的时候碰到的问题很多，但是基本上都是按照wiki上的步骤进行的。我觉得比较重要的几点：

• wiki上的Required Packages包包列表都要检查一遍，比如版本号，是否安装过，像binutils-dev这种就很容易忽略
• 版本符合的话，直接用yum安装这些包就可以了
• wiki上有类似Boost 1.37 is the minimum version字样，说明开发者可能就是在这个版本下开发的，我试了下最新版本的boost，编译到后来反而出错
• 如果yum上没有符合版本的lib库，可以手动编译，但是编译时建议就放在自己的home下，比如：

  ./configure --prefix=/home/user

• tbb Intel’s Thread Building Blocks这个包有些麻烦，记得按照wiki上说的步骤安装

测试hiphop-php

安装完成之后，时间也不是太多，所以我仅仅是简单的测试了一个php文件，代码如下：

<?php
$i = 0;
for($j = 0; $j < 1000000; $j++)
        $i += $j;

echo $i, "\n";
?>

用hphp进行编译:

hphp/hphp test.php --keep-tempdir=1 --log=3

提示生成新的可执行文件

/tmp/hphp_c9sbnG/program

做一下运行时间对比：

$ time php test.php
499999500000

real    0m0.307s
user    0m0.299s
sys     0m0.007s

$ time /tmp/hphp_c9sbnG/program
499999500000

real    0m0.259s
user    0m0.194s
sys     0m0.008s

没看出来编译成c++代码之后有太大的性能提升，估计是俺的使用手法问题？在邮件组里观察几天再说。

Update

facebook将优化之后的编译参数提交到了github，于是我重新编译并测试一遍这段相同的代码：

$ time /tmp/hphp_c9sbnG/program
499999500000

real    0m0.140s
user    0m0.076s
sys     0m0.006s

可以看到，经hiphop编译后的php，执行时间几乎快了一倍。

• 安装卸载，升级rpm软件包只需一条命令即可
• 统一部署，便于维护
• 比手工编译的方式要快

于是我需要把日常使用到的一些php扩展做成rpm包，但是手工写spec文件比较繁琐，因此pear的这个小工具PEAR_Command_Packaging帮了不少忙。它会给pear工具新增一个选项：

pear make-rpm-spec [options] <package-file>

这个命令行将会创建一个rpm的.spec文件，包含指定pear包的定义，而且也适用于pecl的php扩展。

创建pear rpm包的例子

$ cd /path/to/rpm-build-tree/SPECS
$ pear make-rpm-spec ../SOURCES/Net_Socket-1.0.tgz
Wrote RPM spec file PEAR::Net_Socket-1.0.spec
$ rpm -bb PEAR::Net_Socket-1.0.spec
...
Wrote: /path/to/rpm-build-tree/RPMS/noarch/PEAR::Net_Socket-1.0-1.noarch.rpm

关于make-rpm-spec的帮助

pear help make-rpm-spec

作为一个cache，占用了这么长的执行时间，天理何在？

实际的运行环境如下：

• apache + mod_php
• php-memcache扩展版本为2.2.5
• memcache的并发连接数在400左右，相当少

这次memcache扩展用的是最新的稳定版，无可挑剔。所以刚开始我认为是网络环境的问题，于是直接采用telnet工具直连memcache进行测试，发现速度飞快！一点便秘感都没有！所以把目光仍然放回到memcache扩展上来，集中对比较慢的addServer方法各项参数进行排查。

Memcache::addServer方法

bool Memcache::addServer  ( string $host  [, int $port = 11211  [, bool $persistent  [, int $weight  [, int $timeout  [, int $retry_interval  [, bool $status  [, callback $failure_callback  [, int $timeoutms  ]]]]]]]] )

比对结果表明，$weight参数对memcache的连接时间有显著的影响，$weight的默认值为1，一旦设置为别的数值，连接时间便会由毫秒级变成50ms左右，立竿见影。

鉴于php-memcache扩展一贯恶劣的表现，俺不得不痛下决心迁移到新的memcached扩展上。memcached扩展基于libmemcached开发，而且提供了丰富的接口方法，应该是更好的选择。

• apache + php
• 使用smarty模板输出内容
• 页面最终输出内容较大，80k+
• 页面执行时间在500ms以上

祭出法宝xhprof对问题页面做了细致检查，发现页面的瓶颈竟然是模板（编译后的）中的一个echo语句，这个echo语句输出的字符串比较大，大概是50k+字节，花费时间为400多毫秒，占整个页面执行时间的80%。这样的echo输出在站点首页中其实是很常见的事情，没有数据库操作，按道理执行时间不应该这么长。

于是猛力使用搜索技能，最终在php手册的echo部分找到了一些蛛丝马迹，早在2003年就有前辈认为通过echo输出大字符串到客户端会引起服务器的性能问题，据我测试，在这个场景下使用print其实也是一样的慢。建议的解决办法是把字符串切割成更小的字符串输出，展现速度会有提升，输出函数如下：

<?php
function echobig($string, $bufferSize = 8192) {
    $splitString = str_split($string, $bufferSize);
    foreach($splitString as $chunk)
        echo $chunk;
}
?>

但是上面的处方不太对症，整个echobig的输出时间仍然在400毫秒左右，没有太大改善。

考虑到是输出大量内容到客户端比较慢，于是检查了apache的配置，原来还没打开deflate进行压缩，遂启用之。再次使用xhprof进行检查，这条echo的输出时间降低到5ms左右。

400ms到5ms，一个配置问题会产生80倍的差距，还真是省老钱了。这个故事告诉我们，压缩输出真的很重要。

Update

实际上这个问题也可以通过调整webserver的output buffer来解决一部分，参考：

• Why echo is slow in PHP and how to make it really fast
• 加速PHP的ECHO

而xhprof就显得很轻量，是否记录profile可以由程序控制，因此，用在生产环境中也就成为一种可能。在它的文档上可以看到这样一种用法：

以万分之一的几率启用xhprof，平时悄悄的不打枪。

if (mt_rand(1, 10000) == 1) {
 xhprof_enable(XHPROF_FLAGS_MEMORY);
 $xhprof_on = true;
}

在程序结尾处调用方法保存profile

if ($xhprof_on) {
 // stop profiler
 $xhprof_data = xhprof_disable();

 // save $xhprof_data somewhere (say a central DB)
 ...
}

也可以用register_shutdown_function方法指定在程序结束时保存xhprof信息，这样就免去了结尾处判断，给个改写的不完整例子：

if (mt_rand(1, 10000) == 1) {
 xhprof_enable(XHPROF_FLAGS_MEMORY);
 register_shutdown_function(create_funcion('', "$xhprof_data = xhprof_disable(); save $xhprof_data;"));
}

至于日志，我暂时用的是最土的文件形式保存，定期清除即可。

BTW:xhprof生成的图形方式profile真是酷毙了，哪段代码成为瓶颈，一目了然。

bool Memcache::set  ( string $key  , mixed $var  [, int $flag  [, int $expire  ]] )

在这个方法中，将$flag设置为MEMCACHE_COMPRESSED即可启用memcache压缩存储。

这样做有什么弊端？

如果没有做额外判断，每一次写入memcache都会启用压缩，不管数据的大小。对应的，每次获得数据都需要做一次解压缩的操作，这是典型的一刀切手法。实际上在数据很小的情况下，不需要压缩，在这个基础上压缩省不了多少空间。

更好的压缩策略？

好了，我的想法是在数据超过一定大小（比如2k）的情况下，才开启压缩。这个好办，捋起袖子就干，在调用Memcache::set方法之前，首先判断一下数据的大小，一个strlen就搞定了，再简单不过了。

$memcache = new Memcache;
$memcache->connect('localhost', 11211);
$flag = strlen($data) > 2048 ? MEMCACHE_COMPRESSED : 0;
$memcache->set('mykey', $data, $flag);

有人可能会问了，array和object怎么办，这玩意可不能用strlen判断长度。

这还真能难住我一阵子，要知道把array/object写入memcache的时候，php会自动做serialize，再把它当作字符串插入memcache。

$flag = strlen(serialize($data)) > 2048 ? MEMCACHE_COMPRESSED : 0;

谁会采用这段代码？看起来非常山寨，而且serialize也不快，赔本买卖。

更好的办法！

上面的文字都是废话，直接看这段就好。Memcache::setCompressThreshold方法可以包办之前所有的逻辑。

Memcache::setCompressThreshold — Enable automatic compression of large values

bool Memcache::setCompressThreshold  ( int $threshold  [, float $min_savings  ] )

举个例子，下面这段会自动启用压缩策略，当数据大于2k时，以0.2的压缩比进行zlib。

$memcache->setCompressThreshold(2000, 0.2);

根据我的测试结果，setCompressThreshold方法会忽略Memcache::set的flag参数。

什么情况？

原来的url

http://www.xxx.com/demo/oldpage.php?param1=1&param2=2

转换后的url

http://www.xxx.com/newpage.php?url=%2Fdemo%2Fmypage.php%3Fparam1%3D1&param2%3D2

需要把粗体部分的url进行urlencode，能看出上面的字符”?&=”都分别转义过，作为参数发给另外一个url。那么这时候请出rewrite还真是最合适不过了。

坎坷的Rewrite经历

查查rewrite手册，俺这才知道，转义这活，非得派出RewriteMap的map function才能做的比较漂亮。现在只有四个内部map function可供差遣：

• toupper: Converts the key to all upper case.
• tolower: Converts the key to all lower case.
• escape: Translates special characters in the key to hex-encodings.
• unescape: Translates hex-encodings in the key back to special characters.

那么很快就有了第一个rewrite出现：

RewriteMap escape int:escape
RewriteRule ^/([^/]*)$ /newpage.php?mi_url_suffix=${escape:$1?%{QUERY_STRING}} [L,PT]

注：这里的int不是intger的意思，它是internal的缩写，表示调用内部函数。

看上去非常简单，跑起来貌似也正….常？且慢，俺打开RewriteLog一瞅，形式不容乐观啊，”&”字符通通没有转义。看来是失败了，爬到狗狗上翻了一下，貌似escape对”?=”之类的特殊字符是不做转义的，晕。

RewriteMap到底

接着细看apache的rewrite手册，发现RewriteMap还支持自定义脚本，那么还得使出俺的看家绝技——php了。首先弄一个能转义的php，必须非常简单，复杂了apache容易挂掉，写出来发现想复杂都挺难啊：

/usr/local/bin/escape.php

#!/usr/bin/php -f
<?php
while($in = trim(fgets(STDIN)))
        fputs(STDOUT, urlencode($in) . "\r\n");
?>

在这个脚本里可别使用php:://stdin之类的，具体原因查php手册。相应的，rewrite规则如下：

RewriteMap escape prg:/usr/local/bin/escape.php
RewriteRule ^/([^/]*)$ /newpage.php?mi_url_suffix=${escape:$1?%{QUERY_STRING}} [L,PT]

rewrite规则没有太大的改变，prg表示使用自定义脚本。现在这个版本总算正常运作了。

里头有36个程序可供投票，基本上全是脚本语言大杂烩：php,perl,ruby,javascript。实现的应用也是五花八门，有相册，类twitter，小游戏，甚至还有php代码框架？摘录如下：

require __DIR__.'/c.php';
if (!is_callable($c = @$_GET['c'] ?: function() { echo 'Woah!'; }))
        throw new Exception('Error');
$c();

这段代码利用了php5.3的一些新特性：

• __DIR__
• Anonymous functions
• ?:运算符

代码只有131个字符，由于代码极为简陋，安全性也是没得保障的，只能算一个程序的统一入口罢了。

如果用php 5.2来写这段代码，大概就是：

require dirname(__FILE__).'/c.php';
if (!is_callable($c = @$_GET['c'] ? $_GET['c'] : create_function('', "echo 'Woah!';")))
        throw new Exception('Error');
$c();

如果要让这段代码变得实用点，可以在$c前面加上一个前缀，这样安全性会有进一步提升，代码也会相应的增加若干字节。

基本文件文件结构

index.php
/libs/
  Smarty.class.php 		#主文件
/libs/sysplugins/		#内部plugin
  internal.*
/plugins/			#外部plugin,可自由扩充
  function.mailto.php
  modifier.escape.php
/templates/			#模板，可以是纯php或传统的smarty模板
  index.tpl
  index_view.php

一个经典的smarty调用

require('Smarty.class.php');
$smarty = new Smarty;
$smarty->assign('foo','bar');
$smarty->display('index.tpl');

和之前的版本似乎没什么差别

SINGLETON

这个有意义吗？

$smarty = Smarty::instance();

模板

之前的smarty模板，相当于重新定义了一套标签语言，那么smarty3提供了一种新的模板形式，直接支持php语法的模板。

但是问题就出来了，我们还有必要用模板吗？

引用php类型模板的一个例子：

$smarty->display('php:mytemplate.tpl');

模板中可以直接使用熟悉的语法： <?=$foo?> <?=$bar?>

使用php类型模板的话，安全问题需要自己解决。但这个对成熟的团队来说不是问题。

除此之外，新支持字符串类型的模板，感觉比较生猛，离模板之路也是渐行渐远：

$smarty->display('string:This is my template, {$foo}!');

smarty3的相关链接

• Smarty 3 Alpha with SVN — 选择googlecode提供的svn服务还是蛮省钱的
• smarty 3开发者邮件组

Q. How do I install filter extension for safely dealing with input parameters supplied via a web form using filter_var()?
A. This extension is part of PHP Core version 5.20 and above. Unfortunately, RHEL / CentOS comes with PHP version 5.1.6. So you need to install this extension by typing the following commands.

由于RHEL / CentOS自带的php版本是5.1.6，那么只好手工安装filter扩展。安装过程：

安装php-devel

为了编译php extensions，需要安装php-devel包:

# yum install php-devel

下载php的源码

php 5.1.6的源码树中没有包含php_pcre.h header文件, 所以需要另行下载一个php源码. 从php.net下载最新版本的源码并放到/opt目录:

# cd /opt
# elinks http://cn2.php.net/get/php-5.2.6.tar.bz2/from/cn.php.net/mirror

保存之后解压:

# tar -jxvf php-5.2.6.tar.bz2

下载filter extension

在pecl上找到最新的filter源码:

# cd /opt
# wget http://pecl.php.net/get/filter-0.11.0.tgz

安装filter extension

解压文件:

# tar -jxvf filter-0.11.0.tgz
# cd filter-0.11.0

打开logical_filters.c文件:

# vi logical_filters.c

找到下面的代码行:

#include "ext/pcre/php_pcre.h"

修改成 (php_pcre.h的绝对路径):

#include "/opt/php-5.2.6/ext/pcre/php_pcre.h"

保存并关闭文件. 最后输入下面命令来编译filter扩展:

# phpize
# ./configure
# make install

配置Filter Extension

输入下列命令:

# echo 'extension=filter.so' > /etc/php.d/filter.ini

然后重启web server即可。

原文: CentOS / Red Hat Linux Install PHP 5.x PECL Filter Extension

增强的ini文件支持

• CGI/ FastCGI支持类似.htaccess的INI配置
• 每个目录下都可以有INI设置，ini的文件名取决于php.ini的配置，但是[PATH=/var/www/domain.com], [HOST=www.domain.com]段落的设置用户不能修改。
• 增强的error handling
• 允许在ini文件中定义变量和常量，可以在程序中直接调用。

附上一段ini文件的例子

#用户自定义的php.ini文件名 (.htaccess). 默认是".user.ini"
user_ini.filename = ".user.ini"

#如果要禁用这个特性，设置为空值即可
user_ini.filename =

#用户自定义的php.ini文件TTL时长(time-to-live)，单位为秒，我理解为缓存过期时间。默认为300秒
user_ini.cache_ttl = 300

[PATH=/var/www/domain.com]
variables_order = GPC
safe_mode = 1

[my variables]
somevar = “1234”
anothervar = ${somevar} ; anothervar == somevar

[ini arrays]
foo[bar] = 1
foo[123] = 2
foo[] = 3

性能提升

php 5.3的总体性能提升了5 – 15%

• md5()快了10-15%
• Better stack implementation in the engine
• Constants移到read-only内存里
• exception处理过程改进(简化，opcodes更少)
• (require/include)_once改进，去掉重复open
• Smaller binary size & startup size with gcc4

新语言特性

__DIR__

在5.3以前，为了获得当前脚本的目录，需要一次函数调用

echo dirname(__FILE__); // < PHP 5.3

在5.3，只需要一个魔术常量__DIR__就解决了。

echo __DIR__; // >= PHP 5.3

?:操作符

便捷的?:操作符，可以从两个值/表达式中快速取得非空值。

$a = true ?: false; // true
$a = false ?: true; // true
$a = "" ?: 1; // 1
$a = 0 ?: 2; // 2
$a = array() ?: array(1); // array(1);
$a = strlen("") ?: strlen("a"); // 1

__callStatic()

新增了魔术方法__callStatic，功能和__call类似，但是仅对static方法有效。

class helper {
        static function __callStatic($name, $args) {
                echo $name.'('.implode(',', $args).')';
        }
}
helper::test("foo","bar"); // test(foo,bar)

动态调用static方法

动态的调用静态方法？动静结合。

class helper {
        static function foo() { echo __METHOD__; }
}
$a = "helper";
$b = "foo";
$a::$b(); // helper::foo

Late Static Binding

不知道怎么译，可能留个原文更容易理解。静态方法的事件处理时机有变化，以前是在编译期处理，现在是执行期间处理。

在php 5.3之前，下面的代码会输出一个A，但是这不是咱们要的，whoami方法已经在class B中重新定义，它本该输出B才符合咱们想当然的思维。

class A {
   public static function whoami() {
      echo __CLASS__;
   }
   public static function identity() {
     self::whoami();
   }
}
class B extends A {
   public static function whoami() {
      echo __CLASS__;
   }
}
B::identity(); // A <-- PHP < 5.3

下面代码中使用了static::whoami()来调用静态方法。php 5.3之后，由于__CLASS__是在执行期被处理，那么这个例子中能顺利抓到class B。

class A {
   public static function whoami() {
      echo __CLASS__;
   }
   public static function identity() {
      static::whoami();
   }
}
class B extends A {
   public static function whoami() {
      echo __CLASS__;
   }
}
B::identity(); // B <-- >= PHP 5.3

mysqlnd

见mysqlnd成为php 5.3中的默认mysql驱动

但是PDO_MySQL暂时还不支持mysqlnd，目前只有mysql(i)扩展可以用到