-
用git部署php站点
在小站点上，直接用git来部署php代码相当方便，你的远程站点以及本地版本库都有一个版本控制，追踪问题或者回滚是很轻松的事情。下面介绍用git部署时的设置步骤 在远程服务器的设置 假定你需要部署的代码在/var/www/yoursite cd /var/www/yoursite git init . git config receive.denyCurrentBranch ignore git config –bool receive.denyNonFastForwards false cd .git/hooks wget https://gist.githubusercontent.com/volca/9482044/raw/344a590af350b997db3819fa21426dfe8bc140f4/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服务器上设置这个目录不可见。
-
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; }
-
在生产环境中使用php性能测试工具xhprof
xhprof是facebook开源出来的一个php性能测试工具，也可以称之为profile工具，这个词不知道怎么翻译才比较达意。跟之前一直使用的xdebug相比，有很多类似之处。以前对xdebug有一些记录还可以供参考，但是它的缺点是对性能影响太大，即便是开启了profiler_enable_trigger参数，用在生产环境中也是惨不忍睹，cpu立刻就飙到high。 而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真是酷毙了，哪段代码成为瓶颈，一目了然。
-
Memcache的备忘
把memcache使用时的一些细节记录下来. 用memcache保存session的例子，非常简单 <?php $session_save_path = “tcp://$host:$port?persistent=1&weight=2&timeout=2&retry_interval=10, ,tcp://$host:$port “; ini_set(‘session.save_handler’, ‘memcache’); ini_set(‘session.save_path’, $session_save_path); ?> memcache每一个item上限是1M，注意不要超出上限 memcache本身并不支持namespace，但是可以通过一些手段模拟出namespace的效果来，见Memcache 中模拟 namespace 刚接触memcache的时候，可能会写出这样的代码来 $zhang = $memcache->get(‘key1’); $li = $memcache->get(‘key2’); $wang = $memcache->get(‘key3’); 这种写法实际运行效果是 get(key1) – 客户端发出请求 – 服务器端查询 – 客户端获取 get(key2) – 客户端 – 服务器端 – 客户端 get(key3) – 客户端 – 服务器端 – 客户端 … 如此一来，会有三次客户端和服务器端交互的过程。但是如果用批量查询的方法，就只有一次交互的过程。比如: $all = $memcache->get(array(‘key1’, ‘key2’,…
-
查看xdebug profile文件的几个程序
在优化php代码执行效率过程中，有个好办法是利用xdebug生成profile文件，然后查看整个程序的瓶颈在哪里。现在xdebug profile的查看程序有好几个，在这里罗列一下. Wincachegrind Wincachegrind是windows下的profile查看程序，使用起来感觉还不错，profile文件太大的话偶尔会崩溃。 今天在高春辉的博客上看到这些: 最近又开始拿 Xdebug 和 wincachegrind 对项目的 PHP 代码进行分析和优化，但是发现和自己输出的执行时间总是相差十倍，差的不是零头，而是十倍。 上网搜索了一下，原来在 Xdebug 2.0.0RC4 版本开始，对 profiler 日志中的时间单位进行了修改。 （“Use µ seconds instead of a tenths of µ seconds to avoid confusion in profile information. ”） 而 wincachegrind 又不再升级维护了，所以凡是用 2.0.0RC4 以及之后版本的 Xdebug 输出的 profiler 日志用 wincachegrind 来分析的话，都会有十倍的时间差距。 他已经提供了hack后的版本，可以解决时间差距的问题，有兴趣的同学可以试试。 CachegrindVisualizer CachegrindVisualizer是一个xdebug的profile文件查看客户端,采用Adobe的AIR制作。 更详细的介绍可以看以前写的关于CachegrindVisualizer的介绍。 Kcachegrind Kcachegrind是linux下的一个图形化profile查看工具，功能很强劲。 Callgrind uses runtime…
-
用xdebug优化php的三个小窍门
xdebug的2.0正式版已经发布了。这个工具用在php的代码调试，优化方面效果很不错。下面贴上俺使用过程中的几个小窍门。 xdebug生成profile文件，可以用KCachegrind来查看，但是这个工具只在linux下面可用，没有windows下的版本。这里推荐一个win下的免费工具——wincachegrind，也可以查看xdebug的profile文件，用来分析php代码运行情况足够用了（偶尔不太稳定）。 xdebug一般情况下只会对一个请求做profile记录，如果需要查看几个请求的运行情况合集，可以设置xdebug.ini的 xdebug.profiler_aggregate = 1 记得重启你的apache。 如果在xdebug.ini里设置了 xdebug.profiler_enable = 1 那么每次程序运行期间xdebug都会记录profile，这样对程序的运行速度有很大的影响。为了避免这一情况发生，可以让xdebug仅在需要的时候运行——设置 xdebug.profiler_enable_trigger = 1 这样，只有你用get/post方式提交XDEBUG_PROFILE变量的情况下，xdebug才会开始干活。 另:将最新版本的xdebug和APC同时使用，没有出现兼容性问题，运行良好。
-
使用memcache的几个优点
最近在3个项目中都有用到memcache，这东东确实有出人意料的上佳表现，优点不少。 稳定，几个月以来，一同装上去的apache已重启过多次，这期间memcache一直踏踏实实干活，一点都不需要中途加油。 配置简单，那是相当的简单，几乎不用配置，一个命令行的守护进程跑下来，就可以不管了 多机分布式存储，每个前端机都能匀出一些内存来跑memcache，这些内存加在一起，总大小也是相当的客观，能够应付足够多的缓存数据，如果开启了memcache的压缩选项MEMCACHE_COMPRESSED，存储量还能有进一步提升。 速度快，这个论点需要数据支持，俺手头之前有一些不同数据量级下set/get的速度对比，但是这里不方便列出来 以上，俺认为memcache是前端缓存一个漂亮的解决方案
-
参加中国网络侠客行工程师大会
今天在杭州参加阿里巴巴举办的中国网络侠客行工程师大会，首日上午有php创始人Rasmus Lerdorf以及牛人Jeremy Zawodny，议题是PHP on hormones和Web Service APIs: From Mashups to new Businesses。 下午继续听了Rasmus Lerdorf的Performance and Security，他这次用cachegrind来做后端模块的性能分析，php方面直接使用xdebug+kcachegrind，这个组合相当之好，只可惜cachegrind一直没有freebsd下的版本，比较不爽。这期间因为语言不通，听的很累，同声翻译不是专业人士，翻译的也让人是很难受，好在幻灯早就看过，和最早的getting rich from php5很相似，有一些了解。 BTW:与会的学生那是相当之多:)