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发这里吧.
前天看了TimYang的<一个技术从业人员眼中的2014> , 有些观点我很是赞同, 于是我也有了想写点什么的冲动…
在2015年的第二天, 我终于好像有了一些跳跃的想法, 可以说给大家听听. 也许不够体系, 不够完整, 但或许能得到一些共鸣.
Filed in 随笔
with 80 Comments
其实我已经在很多场合说过, PHP7的性能已经和HHVM相当了..
但是呢, 总是有人问…
另外感觉微博并不能特别好的留存, 所以我写个BLOG吧.
这篇BLOG, 我将进行最客观的对比测试, 就用ab来压测一下Wordpress的首页..
来对比看看PHP7和HHVM-3.2.0的性能在Wordpress上的性能对比.
Filed in PHP应用
with 81 Comments
本来是发在长微博的, 不过, 鉴于, 好久没更新博客了…… 就转过来, 凑个数吧, 大家凑合着看 🙂
白忙活了近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的代码中…