某人的栖息地 » php

试着开源LiteCloud项目

Volcano — Mon, 15 Mar 2010 15:47:32 +0000

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

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

项目主页

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

使用示例

用静态方法调用:

PLAIN TEXT

PHP:

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.,: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集群

PLAIN TEXT

PHP:

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.,: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目录下。测试条件如下:

底层采用tokyo tyrant作为存储。
单个进程重复操作一万次，比如写一万次hello => world，这个测试条件和python版本完全一致
关闭了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的前端服务器

Volcano — Sat, 27 Feb 2010 23:55:30 +0000

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

简单的nginx配置示例

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

PLAIN TEXT

CODE:

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

PLAIN TEXT

CODE:

server {
listen *:80;
server_name _;
location / {
deny all;
}
}

快速安装hiphop-php的捷径

Volcano — Sun, 21 Feb 2010 10:55:15 +0000

不得不说，现在安装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

Volcano — Sun, 21 Feb 2010 02:19:22 +0000

昨天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文件，代码如下：

PLAIN TEXT

PHP:

$i = 0;
for($j = 0; $j <1000000; $j++)
$i += $j;
echo $i, "\n";
?>

用hphp进行编译:

PLAIN TEXT

CODE:

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

提示生成新的可执行文件

PLAIN TEXT

CODE:

/tmp/hphp_c9sbnG/program

做一下运行时间对比：

PLAIN TEXT

CODE:

$ 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，于是我重新编译并测试一遍这段相同的代码：

PLAIN TEXT

CODE:

$ time /tmp/hphp_c9sbnG/program
499999500000
real 0m0.140s
user 0m0.076s
sys 0m0.006s

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

快速创建pear/pecl的rpm

Volcano — Mon, 04 Jan 2010 04:32:41 +0000

目前使用的服务器为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连接慢又一例

Volcano — Tue, 22 Dec 2009 13:56:53 +0000

继上次解决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为什么这么慢

Volcano — Tue, 15 Dec 2009 13:38:09 +0000

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

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

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

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

PLAIN TEXT

CODE:

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倍的差距，还真是省老钱了。这个故事告诉我们，压缩输出真的很重要。

在生产环境中使用php性能测试工具xhprof

Volcano — Wed, 05 Aug 2009 14:01:00 +0000

xhprof是facebook开源出来的一个php性能测试工具，也可以称之为profile工具，这个词不知道怎么翻译才比较达意。跟之前一直使用的xdebug相比，有很多类似之处。以前对xdebug有一些记录还可以供参考，但是它的缺点是对性能影响太大，即便是开启了profiler_enable_trigger参数，用在生产环境中也是惨不忍睹，cpu立刻就飙到high。

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

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

PLAIN TEXT

PHP:

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

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

PLAIN TEXT

PHP:

if ($xhprof_on) {
// stop profiler
$xhprof_data = xhprof_disable();
// save $xhprof_data somewhere (say a central DB)
...
}

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

PLAIN TEXT

PHP:

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真是酷毙了，哪段代码成为瓶颈，一目了然。

启用memcached压缩注意事项

Volcano — Wed, 13 May 2009 23:56:05 +0000

在php开发中，开启memcache的数据压缩存储是一件很简单的事情。在多数情况下，压缩数据不仅不会降低程序的执行效率，反倒会因为网络传输的开销降低，带来速度提升。看看最常用的Memcache::set方法:
bool Memcache::set ( string $key , mixed $var [, int $flag [, int $expire ]] )

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

这样做有什么弊端？

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

更好的压缩策略？

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

PLAIN TEXT

PHP:

$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。

PLAIN TEXT

PHP:

$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。

PLAIN TEXT

PHP:

$memcache->setCompressThreshold(2000, 0.2);

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

apache的RewriteMap使用心得

Volcano — Thu, 02 Apr 2009 13:57:47 +0000

在apache的环境下，rewrite还真是生活之友啊，时不时就得用上。前些日子有个需求，要将url重新转一转。

什么情况？

原来的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

PLAIN TEXT

PHP:

#!/usr/bin/php -f
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表示使用自定义脚本。现在这个版本总算正常运作了。

starling试用手记

Volcano — Sat, 21 Mar 2009 10:48:53 +0000

twitter最近将ruby实现的消息队列服务器starling开源了，这是一个支持memcache协议的轻量级持久化服务器，因此使用php/perl/ruby/java等多种客户端都没问题，可以将较慢的处理逻辑通过消息队列放在后台处理，同时也支持多点分布式处理。周末找了个闲置的centos 5机器搭了一套starling试用，配合php的memcache扩展测试一番，有点意思。

starling安装步骤

centos默认不带ruby，得重新装，以下安装步骤都是以root身份跑的。
yum install ruby ruby-devel rubygems gem install memcache-client starling

如果你使用yum找不到ruby的相关包，请记得添加epel repository。安装之后新增的程序：

/usr/bin/starling #一个ruby脚本，starling的服务程序
/usr/bin/starling_top #starling的状态检查程序，可以查看starling的运行状态，类似memcache的状态显示，不同的是能够显示每个key的状态

starling启动后默认会在22122端口蹲点守候。

为了使用方便，我修改了一个starling在centos下的启动脚本，放在/etc/init.d/starling，下载地址：http://customcode.googlecode.com/files/starling。使用方法：
/etc/init.d/starling start|stop|restart

测试程序

以下是在测试中用的php脚本，说实话php在循环比较大的时候没啥优势，但是关键是简单，几行就搞定了。

写入的测试程序

PLAIN TEXT

CODE:

#!/usr/bin/php
$m = new Memcache;
$m->addServer('127.0.0.1', '22122');
$start = microtime(true);
for($i = 0; $i <10000; ++$i) {
//echo $i, "\n";
$m->set('testtesttesttest', '中文测试中文测试中文测试中文测试中文测试中文测试中中文测试中中文中a');
}
echo "time:" . (microtime(true) - $start), "\n";

读出来的测试程序

PLAIN TEXT

CODE:

#!/usr/bin/php
$m = new Memcache;
$m->addServer('127.0.0.1', '22122');
while(1) {
echo $m->get('test'), "\n";
usleep(100); // 休息一下，否则容易cpu 100%
}

性能测试

测试条件:

key的长度16B
value的长度100B,
8个并发写入进程
每个进程插入10,000条记录

平均每个进程花了7秒完成写入操作，那么照这样计算：

10000 * 8 / 7 = 每秒写入11428次

以上测试进行的比较随意，而且我懒得插入大量数据来测试了，这个比较花时间，所以测试结果仅供参考。由于starling是目前twitter在生产环境中运行的，经过实践检验过，稳定性应该不成问题。

131个字符的php framework

Volcano — Tue, 10 Mar 2009 06:40:03 +0000

在friendfeed上看到这个链接 —— The 140 Characters Webapp Challenge!，这个比赛要求用140个字符的代码造就一个web应用。

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

PLAIN TEXT

CODE:

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来写这段代码，大概就是：

PLAIN TEXT

CODE:

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

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

解决memcache连接奇慢问题一例

Volcano — Sat, 07 Mar 2009 03:19:44 +0000

最近用xdebug观察线上程序的运行时间统计，发现往日里跑起来像飞的memcache居然是系统中拖后腿的耗时大户，连接时间特长。

运行环境

webserver是apache + php
php memcache extension版本是3.0.2，当时是最新的beta版...
有4个memcache server可供使用
代码中会利用php的Memcache::addServer依次连接四个memcache，长连接方式

现象

完成四次addServer一共需要300ms以上，但是一旦连接上，获取单个item飞快，时间在3ms以下。
更可恶的问题在于，虽然执行了四次Memcache::addServer，但是实际使用的始终是最后一个memcache，这实在让人崩溃。

问题解决

使用了一点搜索技巧，在pecl.php.net上找到了类似的bug: First get slow when using multiple memcached servers

这个bug的描述如下：

We are monitoring memcached performance and noticed that when we added a second memcached via Memcache::addServer the first get request is always slower than the subsequent ones although we are using persitent memcached connections. Switching from crc32 to fnv hashing didn't help either. Is that delay explainable

看起来是最新的memcache extension有一些问题，尝试将这个扩展降级成最新的稳定版2.2.6，然后重启apache看看，memcache连接过慢的问题果然已经解决。

结论

吃螃蟹果然是要付出代价的。。

关于smarty3的一些说明

Volcano — Sun, 01 Feb 2009 10:10:16 +0000

这些天看到了smarty 3 alpha冒头了，于是花时间做了个走访调查。下面的文字基本上来自其readme：

基本文件文件结构

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调用

PLAIN TEXT

PHP:

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

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

SINGLETON

这个有意义吗？

PLAIN TEXT

PHP:

$smarty = Smarty::instance();

模板

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

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

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

PLAIN TEXT

PHP:

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

模板中可以直接使用熟悉的语法：

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

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

PLAIN TEXT

PHP:

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

smarty3的相关链接

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

在CentOS / Red Hat下安装PHP 5.x PECL Filter Extension

Volcano — Mon, 27 Oct 2008 08:22:30 +0000

php 5.2之后，默认会装有filter extension，这个扩展可以帮助php开发者过滤用户输入的内容，由php的创始人之一Rasmus Lerdorf提供，可以见我早期的文章介绍。

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

php 5.3带来了什么(三)

Volcano — Wed, 24 Sep 2008 08:50:01 +0000

之前介绍的php 5.3的新特性，都是方便开发人员的东东。下面介绍个很讨虚拟主机提供商喜欢的特性。

增强的ini文件支持

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

附上一段ini文件的例子

PLAIN TEXT

CODE:

#用户自定义的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带来了什么(二)

Volcano — Sun, 21 Sep 2008 06:44:53 +0000

接上文

性能提升

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以前，为了获得当前脚本的目录，需要一次函数调用

PLAIN TEXT

CODE:

echo dirname(__FILE__); // < PHP 5.3

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

PLAIN TEXT

CODE:

echo __DIR__; // >= PHP 5.3

?:操作符

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

PLAIN TEXT

CODE:

$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方法有效。

PLAIN TEXT

CODE:

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

动态调用static方法

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

PLAIN TEXT

CODE:

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才符合咱们想当然的思维。

PLAIN TEXT

CODE:

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。

PLAIN TEXT

CODE:

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)扩展可以用到

php 5.3带来了什么(一)

Volcano — Sun, 21 Sep 2008 00:49:31 +0000

之前陆续介绍了php 5.3的一些新特性，正好上周看到ZendCon关于5.3的ppt，介绍的更为详细，那么这里做个归总或者说翻译:)

Namespaces

php 5.3最大的改动，毫无疑问就是Namespaces(此前有一篇相关的PHP Namespaces FAQ)。这给php开发人员带来的好处不少，广为人们所诟病的函数命名问题也得到了解决。

代码更清晰

5.3之前常见的代码，需要自定义前缀区分函数和类名

PLAIN TEXT

CODE:

function MY_wrapper() {}
class MY_DB { }
define('MY_CONN_STR', '');
MY_wrapper();
new MY_DB();
MY_CONN_STR;

使用名称空间之后，代码看上去更加clean。

PLAIN TEXT

CODE:

namespace MY;
function wrapper() {}
class DB { }
const CONN_STR = '';
use MY AS MY;
wrapper();
new DB();
CONN_STR;

一个文件中定义了多个namespace

如果一个文件中定义了多个namespace，应该怎样处理？

PLAIN TEXT

CODE:

namespace LIB;
class MySQL {}
class SQLite {}
$b = new SQLite();
namespace LIB_EXTRA;
class MScrypt {}
$a = new MScrypt();
var_dump(
get_class($a),
get_class($b)
);

以上代码输出为：

PLAIN TEXT

CODE:

string(18) "LIB_EXTRA::MScrypt"
string(11) "LIB::SQLite"

php是解释执行的语言，以上结果合情合理。

namespace的优先级

namespace中定义的函数，类和常量优先，其次才是全局的。

PLAIN TEXT

CODE:

namespace foo;
function strlen($foo) { return htmlentities($foo); }
echo strlen("test"); // test
echo ::strlen("test"); // 4
echo namespace::strlen("test"); // test

namespace和autoload的友情

autoload会根据namespace名称以及class名称来解析类文件位置
仅当namespace和全局范围都没找到class定义的情况下，autoload才会被触发
在namespace中定义的__autoload不会被自动调用

PLAIN TEXT

CODE:

function __autoload($var) { var_dump($var); } // LIB::foo
require "./ns.php"; /*
namespace LIB;
new foo();
*/

namespace一些辅料

PLAIN TEXT

CODE:

namespace really::long::pointlessly::verbose::ns;
__NAMESPACE__; // 新增的魔法常量，表示当前namespace名称
class a{}
get_class(new a()); // really::long::pointlessly::verbose::ns::a
use really::long::pointlessly::verbose::ns::a AS b; // 从名称空间中引用一个类

注：这里的内容节选自pdf Introduction to PHP 5.3 Slides，后文不再复述。

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

Volcano — Wed, 06 Aug 2008 15:15:03 +0000

mysqlnd成为php 5.3中的默认mysql驱动，它有如下优点：

mysqlnd更容易编译: 因为它是php源码树的一个组成部分
mysqlnd和php内部机制结合更紧密，是优化过的mysql驱动
mysqlnd更节省内存，从测试结果来看，比传统的mysql扩展节省40%的内存
mysqlnd更快
mysqlnd提供了丰富的性能统计功能
mysqlnd使用了PHP license以避免不必要的版权纠纷

这个改动应同时对mysql和pdo_mysql扩展生效。

mysqlnd是什么

mysqlnd是mysql原装的php驱动

php 5.3将提供改进的Lambda函数

Volcano — Mon, 21 Jul 2008 01:32:24 +0000

从前的lambda函数

在php里面，传统方法是利用create_function来建立lambda函数，老实说，这个创建过程比较麻烦。拿php手册上的例子来说：

PLAIN TEXT

CODE:

$newfunc = create_function('$a,$b', 'return "ln($a) + ln($b) = " . log($a * $b);');
echo "New anonymous function: $newfunc\n";
echo $newfunc(2, M_E) . "\n";
// outputs
// New anonymous function: lambda_1
// ln(2) + ln(2.718281828459) = 1.6931471805599
?>

上头这样一段代码，恐怕一时半会还看不明白$newfunc到底是怎样的一个lambda函数。

php 5.3的lambda函数语法

改进的lambda基本语法

PLAIN TEXT

CODE:

function & (parameters) use (lexical vars) { body }

创建一个简单lambda函数的例子。下面的例子看上去，语法和javascript甚至很接近了，对于我这样一个由javascript入门到php来的coder来说，这样的代码真是让人瞅着亲切。代码最后的;号是不可省略的，否则会碰到语法错误。

PLAIN TEXT

CODE:

$lambda = function () { echo "Hello World!\n"; };

调用方法很多

PLAIN TEXT

CODE:

$lambda ();
call_user_func ($lambda);
call_user_func_array ($lambda, array ());

在函数中的简单调用

PLAIN TEXT

CODE:

function replace_spaces ($text) {
$replacement = function ($matches) {
return str_replace ($matches[1], ' ', ' ').' ';
};
return preg_replace_callback ('/( +) /', $replacement, $text);
}

甚至可以把lambda函数作为结果返回，这样引申的语法变化会相当丰富，想想javascript就知道了

PLAIN TEXT

CODE:

function getAdder($x) {
return function ($y) use ($x) {
// or: lexical $x;
return $x + $y;
};
}

还可以导入外部变量到lambda函数，通过关键字use完成。如果没有这个关键字，以前可能要通过global来传递这些变量。

PLAIN TEXT

CODE:

function replace_in_array ($search, $replacement, $array) {
$map = function ($text) use ($search, $replacement) {
if (strpos ($text, $search)> 50) {
return str_replace ($search, $replacement, $text);
} else {
return $text;
}
};
return array_map ($map, $array);
}

这个patch由Christian Seiler, Dmitry Stogov提供，目前已经加入到php 5.3。

原文见：Request for Comments: Lambda functions and closures

最简便的清空memcache的方法

Volcano — Sun, 20 Jul 2008 01:08:58 +0000

如果要清空memcache的items，常用的办法是什么？杀掉重启？如果有n台memcache需要重启怎么办？挨个做一遍？

很简单，假设memcached运行在本地的11211端口，那么跑一下命令行：
$ echo ”flush_all” | nc localhost 11211

注：flush并不会将items删除，只是将所有的items标记为expired。

原文：Flushing memcached servers the easy way

memcache遭遇out of memory错误

Volcano — Tue, 15 Jul 2008 09:34:24 +0000

今天在服务器上碰到memcache的out of memory错误，这还是第一次遇到，稍稍有些慌。一共有15台服务器，每台服务器分配了1G内存给memcache，合计有15个G，遇到错误的时候，大概只使用了4个G不到的内存。

现象比较很灵异，设置一个很小的value的时候就会出现这个错误
[root@slave1 bin]# telnet localhost 11211 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. set key1 0 0 2 SERVER_ERROR out of memory

如果设置一个较大的value，反而Stored成功。

翻看了几篇关于memcache内存分配的介绍，大概有一些了解。

其中后一篇有实际操作的介绍，更为实用。根据个人理解先写个大概。

Memcache为了避免产生内存碎片，采用Slab Allocation机制来整理内存。比如某前端机分配了1G内存给memcache，那么它会将内存按照不同尺寸的小块(chunk)分成若干个组(classes)，组的数目不是很固定，每个组分配1M内存。见下图：

当一条记录插入memcache中的时候，首先会寻找一个合适的能足够容纳这条记录的class。比如你insert一条100字节的数据，它会使用128字节的class来存储这条记录，只有28字节被浪费。

如果用memcached-tool来查看memcache的使用情况，会看到类似下面列出的情况。

[root@sql-slave1 bin]# ./memcached-tool localhost
# Item_Size 	Max_age		1MB_pages	Full?
6 64 B 		0 s 		0 		no
7 128 B 	742970 s 	4 		yes
8 256 B		1174852 s 	2 		yes
9 512 B		1279658 s 	1 		yes
10 1 kB		6494118 s 	1 		yes
11 2 kB 	434918 s 	71 		yes
12 4 kB 	917228 s 	140 	yes
13 8 kB 	794192 s 	30 		no
14 16 kB	1373208 s 	6 		yes
15 B 		0 s 		0 		yes
16 B 		0 s 		0 		yes

此时插入一条很小的记录，比如只有2个字节，那么memcache会尝试用最小的class（64字节）来保存这条记录，这时候由于64字节的class已满或未分配内存，写入数据的时候就会遭遇到前面所说的out of memcache错误了。

更糟糕的是，这时候增加cache大小似乎也不能解决问题。可行的办法是利用memcached-tool对内存进行移动操作：
[root@sql-slave1 bin]# ./memcached-tool localhost move 14 6
上面的操作会移动class 14的一个page到class 6。

Memcache的备忘

Volcano — Fri, 20 Jun 2008 08:26:43 +0000

把memcache使用时的一些细节记录下来.

用memcache保存session的例子，非常简单
PLAIN TEXT
CODE:
2. $session_save_path = "tcp://$host:$port?persistent=1&weight=2&timeout=2&retry_interval=10, ,tcp://$host:$port ";
3. ini_set('session.save_handler', 'memcache');
4. ini_set('session.save_path', $session_save_path);
5. ?>
memcache每一个item上限是1M，注意不要超出上限
memcache本身并不支持namespace，但是可以通过一些手段模拟出namespace的效果来，见Memcache 中模拟 namespace
刚接触memcache的时候，可能会写出这样的代码来
PLAIN TEXT
CODE:
1. $zhang = $memcache->get('key1');
2. $li = $memcache->get('key2');
3. $wang = $memcache->get('key3');
这种写法实际运行效果是
- get(key1) - 客户端发出请求 - 服务器端查询 - 客户端获取
- get(key2) - 客户端 - 服务器端 - 客户端
- get(key3) - 客户端 - 服务器端 - 客户端
- ...
如此一来，会有三次客户端和服务器端交互的过程。但是如果用批量查询的方法，就只有一次交互的过程。比如:
PLAIN TEXT
CODE:
1. $all = $memcache->get(array('key1', 'key2', 'key3'));
这样性能会有一些提升。对于其它程序语言来说，也封装了类似get_multi这样的方法。
从数据库从查询获得一个列表，放到memcache里面保存起来是一个不错的主意，但是不要忘记memcache有1m限制。如果列表太大，可以考虑把数据分割开来，然后用key序列来保存这个列表数据，比如event_0_500来保存前500行,用event_0_1000保存500-1000行，在获取的时候可以用前面说的批量get来一次性得到这个列表。
经常观察memcache的大小，以及命中率，方便调整缓存策略