这个是我上周末在"阿里PHP技术沙龙"临时分享的一个主题的PPT, 主要是介绍一下Zend Optimizer Plus(简称O+).
O+是由Zend公司开发的一个PHP性能提升工具, 在PHP5.5开始, 已经随着PHP的源代码一起发布了, 并且也改名为:Opcache.
不同于APC, O+除了是Opcodes Cache以外, 还做了很多的Opcodes优化, 这个PPT就是主要列举了一下主要的优化们.
也不同于eacc, O+做的优化更多一些.
246 search results for "php"
好久没有更新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 Comments上午的时候, 有同事来找我说上周新上线的一个使用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的响应时间急剧上升...
考虑到这个问题可能具有一定的普遍性, 于是我想我还是写一篇文章来介绍下这个坑, 防止后来人再次踩到.
After 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)
Yar(yet another RPC framework, 教主问我为啥都是Ya打头, 呵呵, 因为这样名字好起)是我在3个多月前, 为了解决一个实际的问题, 而开发的一个PHP扩展的, RPC框架, 和现有的RPC框架(xml-rpc, soap)不同, 这是一个轻量级的框架, 支持多种打包协议(msgpack, json, php), 并且最重要的一个特点是, 它是可并行化的..
with 84 Comments最近关于apc.include_once_override的去留, 我们做了几次讨论, 这个APC的配置项一直一来就没有被很好的实现过.
在这里, 我想和大家在此分享下, 这个问题的原因, 以及对我们的一些启示.
关于使用include还是include_once(以下,都包含require_once), 这个讨论很长了, 结论也一直有, 就是尽量使用include, 而不是include_once, 以前最多的理由的是, include_once需要查询一遍已加载的文件列表, 确认是否存在, 然后再加载.
诚然, 这个理由是对的, 不过, 我今天要说的, 是另外一个原因.
Yaf是我在俩年前写的一个PHP扩展的MVC框架. 开发Yaf的目的是为了解决使用框架带来的性能下降的经典矛盾.
最初要感谢百度的同仁们的信任, 以及当时各位老大的支持, 容许也敢于让我"试错", 才让Yaf顺利的度过了"没人敢用"的阶段, 大量的百度的新的产品基于Yaf开发, 让Yaf的稳定性得到了充分的验证, 也普遍的提高了PHP应用的执行效率.
而现在, Yaf的高性能又一次在微博的应用中得到了证明, 通过迁移框架到Yaf, 和一些其他优化手段, 我们成功的让新版微博的TPS提高了76%之多, 响应时间下降了近一半.
然而, 我也看到, 还有不少同学对Yaf有疑虑, 甚至有质疑, 有人认为"使用C写框架? 那不是回退到写CGI的时代了?", 于是我想我有必要写一篇文章, 详细介绍下我对Yaf的一些理解.
首先, 这篇文章不是对@左耳朵耗子的C++的坑真的多吗？一文的反驳, 我只是在我的理解角度说一下我对语言选择的一些感悟.
关于C和C++的争论, 由来已久, 从当年Linus攻击C++是恐怖的语言的时候, 就一直没有停歇, 而就我自己来说, 我对C++的掌握还远远不够, 所以没有能力来从语言设计角度来对比(我在最初, 也尝试学过C++, 用过C++, 但后来发现, 我学不好, 用不好, 就放弃了). 所以我尽量避免在这个方面说错话.
我从来不认为这个问题是个问题, 直到昨天.
昨天晚上的时候, 我提交了一个RFC, 关于引入finally到PHP, 实现这个功能的出发点很简单, 因为我看见不少人的需求, 另外还有就是Stas说, 一直只看到讨论, 没看到有人实现. 于是我就给实现了.
发到邮件组以后, 一个开发组的同学Nikita Popov(nikic), 表示强烈反对这个RFC, 当然最初的论点他说了很多, 最后我们在线讨论的时候, 他表达了一个他的观点:
"PHP在请求结束后会释放所有的资源, 所以我们没有必要调用fclose,或者mysql_close来释放资源, PHP会替我们做"
并且他表示, 他从来都不会调用fclose, 认为fclose的存在只是为了继承C函数族.
我很惊讶, 我也不知道还有多少人是和他一样的想法, 所以我决定写这篇文章.
Can't find what you're looking for? Try refining your search: