关于“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官方的开发人员们情何以堪?

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使用情况的设想

自从去年将xhprof用在生产环境以来,对生产环境的程序调试,性能优化都带来很多便利。但是在使用过程中,还是有一些细节需要改善。

问题

    • 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 vs serialize vs json_encode

最近看到memcached扩展支持额外的序列化方式 — igbinary,这是一个未收录到pecl的php扩展,它提供的两个主要方法:

    • 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又被甩了几条街。

一图顶千言

柱状图越矮小的性能越好
igbinary vs serialize vs json_encode 速度比较

试着开源LiteCloud项目

所谓LiteCloud,无非就是前些天提到的LightCloud的php版本实现。这个和原来的python版本有一些区别,会造成不兼容,如下:

    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做为hiphop-php的前端服务器

在邮件组里看到有人问能不能把多个hiphop-php编译后的程序跑在同一个端口上,想想也是合理的要求。如果一个服务器上跑了多个站点,那肯定都得用80端口,当大家共同租用服务器的时候,这个需求更为强烈。当时我所想到的解决办法是在前面搭个nginx之类的做代理,实际编译后的程序跑在别的端口,然后没过几天就看到了这份wiki – Using nginx as front server to HipHop

简单的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;
	}
}

快速安装hiphop-php的捷径

不得不说,现在安装hiphop-php实在是太麻烦了,如果有rpm包一次搞定那该多好?就说周边那些零散的依赖库,也有不少安装比较繁琐的硬骨头。

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位操作系统。

初次体验hiphop-php

昨天facebook在github上发布了hiphop-php的源代码。之前听说这玩意能把php代码翻译成c++代码,然后带来巨大的性能提升,所以第一时间编译了一份hiphop-php。

我的机器环境是

  • 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,执行时间几乎快了一倍。

快速创建pear/pecl的rpm

目前使用的服务器为centos,使用yum以及rpm来维护系统好处多多:

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

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

pear make-rpm-spec [options] 

这个命令行将会创建一个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

memcache连接慢又一例

上次解决memcache连接慢问题以来,好长一段时间没在这个问题上翻过跟头。这一次我又在生产环境观察到php和memcache的连接时间经常会在50ms以上。

作为一个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开发,而且提供了丰富的接口方法,应该是更好的选择。

php的echo为什么这么慢

作为一个行走江湖多年的老中医,今天受命去解决一例前端页面展现缓慢的问题。问题页的情况如下:

    • 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来解决一部分,参考: