风雪之隅(鸟哥)

PHP7已经发布了, 作为PHP10年来最大的版本升级, 最大的性能升级, PHP7在多放的测试中都表现出很明显的性能提升, 然而, 为了让它能发挥出最大的性能, 我还是有几件事想提醒下.

这是我写在微信公众号里的一篇感想, 突然想起来博客好久没更新了, 感慨一下现在的产品发展的, 个人博客好像越来越没有存在的价值了.... 唉, 不管怎么说, 我稍微做了一些修改以后, 转贴过来.. 做开源也有4, 5年的时间了, 从最初的Yaf, 到今天的PHP7, 我参与的项目越来越多, 使用我代码的用户也越来越多, 而昨天发布的PHP7, 绝对是我从事开源以来的一个最重要里程碑, 我应该纪念一下今天, 就让我稍微感性一次吧.

PHP7刚刚发布了RC4, 包含一些bug修复和一个我们最新的性能提升成果（NEWS）， 那就是"HugePageFy PHP TEXT segment"， 通过启用这个特性，PHP7会把自身的TEXT段（执行体）”挪“到Huagepage上，之前的测试，我们能稳定的在Wordpress上看到2%~3%的QPS提升。 关于Hugepage是啥，简单的说下就是默认的内存是以4KB分页的，而虚拟地址和内存地址是需要转换的， 而这个转换是要查表的，CPU为了加速这个查表过程都会内建TLB（Translation Lookaside Buffer）， 显而易见如果虚拟页越小，表里的条目数也就越多，而TLB大小是有限的，条目数越多TLB的Cache Miss也就会越高， 所以如果我们能启用大内存页就能间接降低这个TLB Cache Miss，至于详细的介绍，Google一搜一大堆我就不赘述了，这里主要说明下如何启用这个新特性， 从而带来明显的性能提升。

我们一直致力于提升PHP7的性能, 上个月我们注意到GCC的PGO能在Wordpress上能带来近10%的性能提升, 这个让我们很激动. 然而, PGO正如名字所说(Profile Guided Optimization 有兴趣的可以Google), 他需要用一些用例来获得反馈, 也就是说这个优化是需要和一个特定的场景绑定的. 你对一个场景的优化, 也许在另外一个场景就事与愿违了. 它不是一个通用的优化. 所以我们不能简单的就包含这些优化, 也无法直接发布PGO编译后的PHP7. 当然, 我们正在尝试从PGO找出一些共性的优化, 然后手工Apply到PHP7上去, 但这个很明显不能做到针对一个场景的特别优化所能达到的效果, 所以我决定写这篇文章简单介绍下怎么使用PGO来编译PHP7, 让你编译的PHP7能特别的让你自己的独立的应用变得更快.

这个项目其实不是一个新的idea, 这个是我在来微博以后, 第一个优化项目中顺手做的一个小工具, 本身叫做Weibo_Conf. 但是因为Weibo_Conf是属于Weibo扩展的, 里面还有一些其他功能是专门为Weibo定制的. 所以不适合直接开源. 随着PHP7的发布, 新增了很多持久化类型的支持比如IS_IMMUTABLE_ARRAY, 于是我就在PHP7下重新开发了Yaconf, 开源出来, 方便大家使用.

PHP5.5一个比较好的新功能是加入了对迭代生成器和协程的支持.对于生成器,PHP的文档和各种其他的博客文章已经有了非常详细的讲解.协程相对受到的关注就少了,因为协程虽然有很强大的功能但相对比较复杂, 也比较难被理解,解释起来也比较困难. 这篇文章将尝试通过介绍如何使用协程来实施任务调度, 来解释在PHP中的协程. 我将在前三节做一个简单的背景介绍.如果你已经有了比较好的基础,可以直接跳到“协同多任务处理”一节.

这个问题, 早在1年前就遇到了, 当时因为没有在意一直没有跟进. 最近团队来了个新人, 又一次触发了这个问题, 所以终于下定决定要好好找找这个BUG的原因.. 首先,这篇文章是个流水账, 没啥意思, 其次最终我其实也没能真正找到原因, 只是找到了一个规避的方法, 和一个猜测的原因. 万一遇到类似情况的同学可以部分借鉴, 当然, 最后我是希望有人对glibc源码熟悉的同学, 可以真正的指点下这个bug的真实原因是啥. 问题是这样的, 我们的一个服务, 依赖于Yar C库, 但是valgrind检测会报告一个问题:

不少同学对于PHP7, 还是了解的不多, 这次在Qcon 2015 北京上我做了一个关于PHP7的分享, 主要内容是PHP7的主要新特性和大幅的性能提升(已经和HHVM的性能不相伯仲). 重点是介绍我们都做了那些性能优化手段, 最后的成果是咋样. 虽然之前在微博上发过, 但是还是有人不时的私信问我PPT, 考虑到微博对搜索引擎的不友好, 我就把PPT发这里吧.

其实我已经在很多场合说过, PHP7的性能已经和HHVM相当了.. 但是呢, 总是有人问... 另外感觉微博并不能特别好的留存, 所以我写个BLOG吧. 这篇BLOG, 我将进行最客观的对比测试, 就用ab来压测一下Wordpress的首页.. 来对比看看PHP7和HHVM-3.2.0的性能在Wordpress上的性能对比.

本来是发在长微博的, 不过, 鉴于, 好久没更新博客了...... 就转过来, 凑个数吧, 大家凑合着看 :) 白忙活了近2个小时,不吐不快: 一切要从今天下午5点左右说起, 调试一个扩展, 用valgrind(valgrind-3.8.1)做例行检查, 很不幸的valgrind报告invalid read:

最近我们的服务在升级php使用的libcurl, 期望新版本的libcurl支持毫秒级的超时, 从而可以更加精细的控制后端的接口超时, 从而提高整体响应时间. 但是, 我们却发现, 在我们的CentOS服务器上, 当你设置了小于1000ms的超时以后, curl不会发起任何请求, 而直接返回超时错误(Timeout reached 28). 原来, 这里面有一个坑, CURL默认的, 在Linux系统上, 如果使用了系统标准的DNS解析, 则会使用SIGALARM来提供控制域名解析超时的功能, 但是SIGALARM不支持小于1s的超时, 于是在libcurl 7.28.1的代码中...

这个是我上周末在"阿里PHP技术沙龙"临时分享的一个主题的PPT, 主要是介绍一下Zend Optimizer Plus(简称O+). O+是由Zend公司开发的一个PHP性能提升工具, 在PHP5.5开始, 已经随着PHP的源代码一起发布了, 并且也改名为:Opcache. 不同于APC, O+除了是Opcodes Cache以外, 还做了很多的Opcodes优化, 这个PPT就是主要列举了一下主要的优化们. 也不同于eacc, O+做的优化更多一些.

这个PPT以前已经在微盘上分享过了, 今天突然想起来, 上传到了slideshare上, 顺便也在博客上留个纪念吧. 这个PPT介绍了过去一年我在微博的工作成果, 包括Yaf的改, 以及新东西Yar, Yac等 通过一系列的努力(整体方针是, 先提速, 降成本, 清晰架构, SOA), 我们让微博首页的响应时间下降了一倍多, 同时还降低了整体的成本.

首先, 太久不更新博客了, 容我先啰嗦几句. 我一直以为人总是会挤出时间写博客的, 但现在看来我错了. 博客很久不更新, 倒不是说没有内容可以分享. 而是这一年来确实忙了很多, 本身工作上的事情就很多, 业余时间也被PHP项目上的事情, Zend的事情填满. 再加上一些小感悟也都在微博上牢骚了... 所以.... Anyway, 很感谢各位经常来我博客的朋友, 不过我建议大家如果是提问的话, 不要在留言里, 有的时候会被博客当做SPAM, 有一些小问题, 可以来微博At我 @laruence 言归正传, 今天分享个前天刚刚做的小工具, 代码可以在我的github上找到: php-valgrind. 这个工具主要是为PHP脚本提供了可以在脚本中开启Valgrind(严格说是Callgrind)的Profile能力.

关于PHP的浮点数, 我之前写过一篇文章: 关于PHP浮点数你应该知道的(All ‘bogus’ about the float in PHP) 不过, 我当时遗漏了一点, 也就是对于如下的这个常见问题的回答: <?php $f = 0.58; var_dump(intval($f * 100)); //为啥输出57 ?> 为啥输出是57啊? PHP的bug么? 我相信有很多的同学有过这样的疑问, 因为光问我类似问题的人就很多, 更不用说bugs.php.net上经常有人问... 要搞明白这个原因, 首先我们要知道浮点数的表示

好久没有更新blog了, 这一年来的工作确实很忙..... anyway, 今天终于有新东西可以和大家分享. 这个idea来自一个很简单的想法, 以及目前所遇到的一个机会. 首先我们来谈谈这个机会. 在以前, 很多人都会选择使用APC, APC除了提供Opcode Cache以外, 还会提供一套User Data Cache(apc_store/apc_fetch), 所以对于很多有需求使用User Data Cache的同学, 使用APC, 就没什么问题. 然而, 最近Zend Optimizer Plus开源了, 测试表明, Zend O+在Opcode Cache方面, 因为做了Opcode Cache优化, 所以会比APC要高效, 再后来, PHP5.5已经把Zend O+作为了源代码的一部分. 会随着PHP一起发布. 这就有了个问题, 对于那些既要使用Zend O+的Opcode Cache, 又要使用APC的User Data Cache的同学, 怎么办呢? 开始的时候, 我只是给APC增加了一个开关apc.opcode_cache_enable, 这样一来, 用户就可以使用APC然而关闭opcode cache来达到这个目的, 但是APC的User Data Cache使用的存储机制是和Opcode Cache一样的, 这样的场景要求数据严格正确, 所以锁会比较多, 测试表明, APC的User Data Cache的效率和本地memcached几乎相当. 所以, 我想到了这个idea, 单独开发一个基于共享内存的, 高性能的User Data Cache

废话不多说, 直接看代码: <?php $dbh = new PDO('mysql:host=localhost;dbname=test', "test"); $query = <<prepare($query); $bind_params = array(':username' => "laruence", ':password' => "weibo"); foreach( $bind_params as $key => $value ){ $statement->bindParam($key, $value); } $statement->execute(); 请问, 最终执行的SQL语句是什么, 上面的代码是否有什么问题?

上午的时候, 有同事来找我说上周新上线的一个使用mcrypt的脚本, 响应非常慢, 但是服务器的各项指标都正常, 不知道是什么原因. 经过了解, 一个简单的可重现的脚本如下: <?php $dmcryptText = "dummy"; $key = "foobar"; $size = mcrypt_get_iv_size(MCRYPT_BLOWFISH,MCRYPT_MODE_ECB); $iv = mcrypt_create_iv($size); //注意这里 $m = mcrypt_ecb(MCRYPT_BLOWFISH, $key, $dmcryptText, MCRYPT_DECRYPT, $iv); var_dump($m); 当20个并发请求这个脚本的时候, 我们会发现Apache的响应时间急剧上升... 考虑到这个问题可能具有一定的普遍性, 于是我想我还是写一篇文章来介绍下这个坑, 防止后来人再次踩到.