这个是我上周末在"阿里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
最近关于apc.include_once_override的去留, 我们做了几次讨论, 这个APC的配置项一直一来就没有被很好的实现过.
在这里, 我想和大家在此分享下, 这个问题的原因, 以及对我们的一些启示.
关于使用include还是include_once(以下,都包含require_once), 这个讨论很长了, 结论也一直有, 就是尽量使用include, 而不是include_once, 以前最多的理由的是, include_once需要查询一遍已加载的文件列表, 确认是否存在, 然后再加载.
诚然, 这个理由是对的, 不过, 我今天要说的, 是另外一个原因.
关于让"PHP的编译和执行分离"这个问题, 一直有人提, 也一直有人尝试. 提的人认为编译执行分离以后, 可以得到性能提升, 可以做代码保护等.
我本身并不是对这个特性很感冒, 因为这里面存在一个投入产出比. 让我来给大家解释一下, 然而不管怎么样, 在最后我会给大家提供一种方案来实现这个功能.
文件上传进度反馈, 这个需求在当前是越来越普遍, 比如大附件邮件. 在PHP5.4以前, 我们可以通过APC提供的功能来实现. 或者使用PECL扩展uploadprogress来实现.
虽然说, 它们能很好的解决现在的问题, 但是也有很明显的不足:
- 1. 他们都需要额外安装(我们并没有打算把APC加入PHP5.4)
- 2. 它们都使用本地机制来存储这些信息, APC使用共享内存, 而uploadprogress使用文件系统(不考虑NFS), 这在多台前端机的时候会造成麻烦.
从PHP的角度来说, 最好的储存这些信息的地方应该是SESSION, 首先它是PHP原生支持的机制. 其次, 它可以被配置到存放到任何地方(支持多机共享).
正因为此, Arnaud Le Blanc提出了针对Session报告上传进度的RFC, 并且现在实现也已经包含在了PHP5.4的主干中.
昨天环境迁移, 脚本出core, 因为之前的环境上运行正常, 所以初步认为是环境问题. 通过对core文件的分析, 初步发现原因和spl_autoload相关, backtrace如下:
#0 zif_spl_autoload (ht=Variable "ht" is not available.)
at /home/huixinchen/package/php-5.2.11/ext/spl/php_spl.c:310
310 if (active_opline->opcode != ZEND_FETCH_CLASS) {
(gdb) bt
#0 zif_spl_autoload (ht=Variable "ht" is not available.
) at /home/huixinchen/package/php-5.2.11/ext/spl/php_spl.c:310
#1 0x00000000006a5da5 in zend_call_function (fci=0x7fbfffc100,
fci_cache=Variable "fci_cache" is not available.)
at /home/huixinchen/package/php-5.2.11/Zend/zend_execute_API.c:1052
.....
脚本很简单, 通过session_set_save_handler注册了一个类为session的user handler.
去掉spl_autoload以后, 不出core了, 但是每次都会抛出Class not found的异常, 可见core确实和spl_autoload有关, 但是这个Class ** not found的fatal error问题又和什么相关呢, 这个fatal error是否是导致spl_autoload core 的直接原因呢?
代码本身并没有任何问题, 对环境做了对比以后, 初步认定为新环境启用了APC的缘故.
在bug.php中找到了有人报告类似的bug(spl_autoload crashes when called in write function of custom sessionSaveHandler), 但没有任何一个人给出原因,或者解决的办法.
看来, 只能自己分析了....
Filed in PHP源码分析
with 17 Comments