git svn实战

我之前写了几个wordpress插件,比如inline-javascript, code-prettify。这些插件都托管在wordpress.org提供的svn服务器上,但是我实在太喜欢在git下活动了,因此动了点心思,想把插件代码传到github上,开发完之后利用git-svn传到wordpress的svn服务上。

照着这个思路,捋起袖子就开干了。

用git-svn抓取插件代码

wordpress的插件svn库大且缓慢,如果直接用git-svn去clone代码,一定会慢死,所以我按照以前的笔记,用git从大型svn快速clone代码

以code-prettify插件为例,首先需要读取这个插件创建时的版本号

svn log http://svn.wp-plugins.org/code-prettify|tail -4|head -1

得到了如下信息,获得一个版本号 318479

r318479 | plugin-master | 2010-12-03 20:12:29 +0800 (五, 03 12 2010) | 1 line

开始clone代码

git svn clone -s --prefix=svn/ -r318479:HEAD http://svn.wp-plugins.org/code-prettify

设置git仓库

首先把代码传了一份到github: https://github.com/volca/code-prettify

然后操作本地git仓库

git branch -m svn
git remote add origin git@github.com:volca/code-prettify.git
git checkout master

本地svn分支对应svn的远程仓库,本地master分支对应github的远程仓库

Happy time

现在可以按照平常的习惯在git下更改代码,然后用git push到github上。

如果需要更新代码到svn上,按这个流程操作就可以了:

git checkout svn
git merge master
git svn dcommit

如果需要发布wordpress插件的新版本,这个在svn里就是一个打tag的过程,用git-svn操作非常简单,下面的例子表示发布code-prettify插件的0.3版本:

git svn tag 0.3

防止伪造跨站请求的小招式

伪造跨站请求介绍

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

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

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

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

随机串代码实现

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

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

应用示例

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

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


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

新增或改动的代码如下:

    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的filter扩展小技巧

做为一个合格的web开发人员,一定会牢记一个原则——永远不能相信用户输入的数据,行走江湖,安全第一是很重要的。用户通过表单或url传过来的数据,一定要仔细检查过了,才往后台数据库里存进去。在一个成熟的开发团队里,贯彻这个原则不成问题;但是如果在一个新人老手混搭的小team里,很容易就忽视了这个问题,那么各种安全漏洞比如跨站攻击,sql注入等等真是防不胜防。

实际上,用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社区,但是暂时没找到出处。

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