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一搜一大堆我就不赘述了,这里主要说明下如何启用这个新特性, 从而带来明显的性能提升。
58 search results for "cp"
我们一直致力于提升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中的协程.
我将在前三节做一个简单的背景介绍.如果你已经有了比较好的基础,可以直接跳到“协同多任务处理”一节.
其实我已经在很多场合说过, PHP7的性能已经和HHVM相当了..
但是呢, 总是有人问...
另外感觉微博并不能特别好的留存, 所以我写个BLOG吧.
这篇BLOG, 我将进行最客观的对比测试, 就用ab来压测一下Wordpress的首页..
来对比看看PHP7和HHVM-3.2.0的性能在Wordpress上的性能对比.
这个是我上周末在"阿里PHP技术沙龙"临时分享的一个主题的PPT, 主要是介绍一下Zend Optimizer Plus(简称O+).
O+是由Zend公司开发的一个PHP性能提升工具, 在PHP5.5开始, 已经随着PHP的源代码一起发布了, 并且也改名为:Opcache.
不同于APC, O+除了是Opcodes Cache以外, 还做了很多的Opcodes优化, 这个PPT就是主要列举了一下主要的优化们.
也不同于eacc, O+做的优化更多一些.
好久没有更新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 = <<<query INSERT INTO `user` (`username`, `password`) VALUES (:username, :password); QUERY; $statement = $dbh->prepare($query); $bind_params = array(':username' => "laruence", ':password' => "weibo"); foreach( $bind_params as $key => $value ){ $statement->bindParam($key, $value); } $statement->execute();
请问, 最终执行的SQL语句是什么, 上面的代码是否有什么问题?
with 80 CommentsAfter Yaf, there comes another PHP framework in extension(在Yaf发布以后, 又出现了一个PHP扩展的框架 Phalcon): Phalcon.
then there raise a problem, which people have asked multi-times to me, that is , which one is the *fastest*(于是就出现一个问题, 不停的有人问, 到底Yaf和Phalcon哪个快, 因为他们都在他们的主页上宣称是最快的框架)? Yaf, or Phalcon. as they both declared they are the fastest(Yaf, Phalcon)
Yaf是我在俩年前写的一个PHP扩展的MVC框架. 开发Yaf的目的是为了解决使用框架带来的性能下降的经典矛盾.
最初要感谢百度的同仁们的信任, 以及当时各位老大的支持, 容许也敢于让我"试错", 才让Yaf顺利的度过了"没人敢用"的阶段, 大量的百度的新的产品基于Yaf开发, 让Yaf的稳定性得到了充分的验证, 也普遍的提高了PHP应用的执行效率.
而现在, Yaf的高性能又一次在微博的应用中得到了证明, 通过迁移框架到Yaf, 和一些其他优化手段, 我们成功的让新版微博的TPS提高了76%之多, 响应时间下降了近一半.
然而, 我也看到, 还有不少同学对Yaf有疑虑, 甚至有质疑, 有人认为"使用C写框架? 那不是回退到写CGI的时代了?", 于是我想我有必要写一篇文章, 详细介绍下我对Yaf的一些理解.
Can't find what you're looking for? Try refining your search: