关于PHP，很多人的直观感觉是PHP是一种灵活的脚本语言，库类丰富，使用简单，安全，非常适合WEB开发，但性能低下。PHP的性能是否真的就如同大家的感觉一样的差呢？本文就是围绕这么一个话题来进行探讨的。从源码、应用场景、基准性能、对比分析等几个方面深入分析PHP之性能问题，通过真实的性能数据来说话，最终找出影响PHP模块性能的关键因素。

1. 大话 PHP 之性能
xuliqiang@baidu.com http://blog.xiuwz.com
摘要
关于 PHP，很多人的直观感觉是 PHP 是一种灵活的脚本语言，库类丰富，使用简单，
安全，非常适合 WEB 开发，但性能低下。PHP 的性能是否真的就如同大家的感觉一样的差
呢？本文就是围绕这么一个话题来进行探讨的。从源码、应用场景、基准性能、对比分析等
几个方面深入分析 PHP 之性能问题，通过真实的性能数据来说话，最终找出影响 PHP 模块
性能的关键因素。
Tag：PHP，性能，C/C++，对比测试
1 缘起
关于 PHP，很多人的直观感觉是 PHP 是一种灵活的脚本语言，库类丰富，使用简单，
安全，非常适合 WEB 开发，但性能低下。PHP 的性能是否真的就如同大家的感觉一样的差
呢？本文就是围绕这么一个话题来进行探讨的。从源码、应用场景、基准性能、对比分析等
几个方面深入分析 PHP 之性能问题，通过真实的性能数据来说话，最终找出影响 PHP 模块
性能的关键因素。
2 从原理分析 PHP 性能
从原理分析 PHP 的性能，主要从以下几个方面：内存管理、变量、函数、运行机制、
网络模型来进行分析。
2.1 内存管理
类似 Nginx 的内存管理方式，PHP 在内部也是基于内存池，并且引入内存池的生命周期
概念。在内存池方面，PHP 对 PHP 脚本和扩展的所有内存相关操作都进行了托管。对大内
存和小内存的管理采用了不同的实现方式和优化，具体可以参考以下文档：
https://wiki.php.net/internals/zend_mm。在内存分配和回收的生命周期内，PHP 采用一次初
始化申请+动态扩容+内存标识回收机制，并且在每次请求结束后直接对内存池进行重新
mask。
2.2 变量
众所周知，PHP 是一种弱变量类型的语言，所以在 PHP 内部，所有的 PHP 变量都对应
成一种类型 Zval，其中具体定义如下：

2. 图一、PHP 变量
在变量方面，PHP 做了大量的优化工作，比如说 Reference counting 和 copy on writer 机
制。这样能够保证内存使用上的优化，并且减少内存拷贝次数（请参考
。在数组方面，PHP 内部采用高效
http://blog.xiuwz.com/2011/11/09/php-using-internal-zval/）
的 hashtable 来实现。
2.3 函数
在 PHP 内部，所有的 PHP 函数都回转化成内部的一个函数指针。比如说扩展中函数
ZEND_FUNCTION ( my_function );//类似 function my_function(){}
在内部展开后就会是一个函数
void zif_my_function ( INTERNAL_FUNCTION_PARAMETERS );
void zif_my_function(
int ht,
zval * return_value,
zval * this_ptr,
int return_value_used,
zend_executor_globals * executor_globals
);
从这个角度来看，PHP 函数在内部也是对应一个函数指针。
2.4 运行机制
在话说 PHP 性能的时候，很多人都会说“C/C++是编译型，JAVA 是半编译型，PHP 是解
释型” 。也就是说 PHP 是先动态解析再代码运行的，所以从这个角度来看，PHP 性能必然很
差。的确，从 PHP 脚本运行来输出，的确是一个动态解析再代码运行的过程。具体来说，
PHP 脚本的运行机制如下图所示：

3. 图二、PHP 运行机制
PHP 的运行阶段也分成三个阶段：
 Parse。语法分析阶段。
 Compile。编译产出 opcode 中间码。
 Execute。运行，动态运行进行输出。
通过上图也可以看出，其实在 PHP 内部本身也是存在编译的过程。事实上，在标准的
生产环境中，也都基本上利用了这个特点，比如说 opcode cache 工具 apc、eacc、xcache 等
等。基于 opcode cache，能到做到“PHP 脚本编译一次，多次运行”的效果。从这点上，PHP
就和 JAVA 的半编译机制非常类似。
所以， 从运行机制上来看， PHP 的运行模式和 JAVA 是非常类似的，都是先产生中间码，
然后运行在不同虚拟机上。
2.5 动态运行
从上面的几个分析来看，PHP 在内存管理、变量、函数、运行机制等几个方面都做了大
量的工作， 所以从原理来看， PHP 不应该存在性能问题， 性能至少也应该和 JAVA 比较接近。
但为什么还有很多人感觉 PHP 慢呢？尤其是一些计算量的性能对比上，总发现 PHP 处
理的性能相对比较低效（http://shootout.alioth.debian.org/u32/php.php） 。这个时候就不得不
谈 PHP 动态语言的特性所带来的性能问题了，由于 PHP 是动态运行时，所以所有的变量、
函数、对象调用、作用域实现等等都是在执行阶段中才确定的。这个从根本上决定了 PHP
性能中很难改变的一些东西：在 C/C++等能够在静态编译阶段确定的变量、函数，在 PHP
中需要在动态运行中确定，也就决定了 PHP 中间码不能直接运行而需要运行在 Zend Engine
上。
说到 PHP 变量的具体实现， 又不得不说一个东西了： hashtable。Hashtable 可以说在 PHP
灵魂之一， PHP 内部广泛用到，
在 包含变量符号栈、函数符号栈等等都是基于 hashtable 的。
以 PHP 变量为例来说明下 PHP 的动态运行特点，比如说代码：
<?php
$var = “hello, blog.xiuwz.com”;
?>
该代码的执行结果就是在变量符号栈（是一个 hashtable）中新增一个项
‘var’-zval (value:”hello, blog.xiuwz.com”, refcount=1, is_ref=0)
当要使用到该变量时候，就去变量符合栈中去查找（也就是变量调用对出了一个 hash

4. 查找的过程）。
同样对于函数调用也基本上类似有一个函数符号栈（hashtable）
。
其实关于动态运行的变量查找特点，在 PHP 的运行机制中也能看出一些。PHP 代码通
过解释、编译后的流程下图：
图 3、PHP 运行实例
从上图可以看出， 代码在 compile 之后，
PHP 产出的了类符号表、 函数符号表、 OPCODE。
和
在真正执行的时候，zend Engine 会根据 op code 去对应的符号表中进行查找，处理。
从某种程度上，在这种问题的上，很难找到解决方案。因为这是由于 PHP 语言的动态
特性所决定的。但是在国内外也有不少的人在寻找解决方案。因为通过这样，能够从根本上
完全的优化 PHP。典型的列子有 facebook 的 hiphop(https://github.com/facebook/hiphop-php)。
但所有的这种编译优化方案，都基本上是牺牲了 PHP 动态运行的特性。当然可以在具
体的编译优化中去对动态特性做一些折中，但很难做到完完全全的兼容。
2.6 网络模型
目前采用 PHP 的方式，比较理想和通用的模式是采用 fastcgi（PHP-FPM）
。Php-fpm 在网
络模型上比较类似 nginx，采用了多进程 Master+多 worker 的模式。Php-fpm 本身是基于
libevent 中的 epoll 模型。从网络模型来看，该方式也不会和其他网络模型存在性能差异。
2.7 结论
从上面分析来看，在基础的内存管理、变量、函数、运行机制、网络模型方面，PHP 本

5. 身并不会存在明显的性能差异，但由于 PHP 的动态运行特性，决定了 PHP 和其他的编译型
语言相比，所有的变量查找、函数运行等等都会多一些 hash 查找的 CPU 开销和额外的内存
开销，至于这种开销具体有多大，可以通过后续的基准性能和对比分析得出。
因此，也可以大体看出 PHP 不太适合的一些场景：大量计算性任务、 大数据量的运算、
内存要求很严格的应用场景。如果要实现这些功能，也建议通过扩展的方式实现，然后再提
供钩子函数给 PHP 调用。这样可以减低内部计算的变量、函数等系列开销。
3 基准性能
对于 PHP 基准性能，目前缺少标准的数据。大多数同学都存在感性的认识，有人认为
800QPS 就是 PHP 的极限了。此外，对于框架的性能和框架对性能的影响很没有响应的权威
数字。
本章节的目的是给出一个基准的参考性能指标，通过数据给大家一个直观的了解。
具体的基准性能有以下几个方面：
1、 裸 PHP 性能。完成基本的功能。
2、 裸框架的性能。只做最简单的路由分发，只走通核心功能。
3、 标准模块的基准性能。所谓标准模块的基准性能，是指一个具有完整功能的模块的
基准性能。
3.1 环境说明
测试环境：
Uname -a
Linux db-forum-test17.db01.baidu.com 2.6.9_5-7-0-0 #1 SMP Wed Aug 12 17:35:51 CST 2009
x86_64 x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
8 Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
软件相关：
Nginx：
nginx version: nginx/0.8.54 built by gcc 3.4.5 20051201 (Red Hat 3.4.5-2)
Php5：（采用 php-fpm）
PHP 5.2.8 (cli) (built: Mar 6 2011 17:16:18)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
bingo2：
PHP 框架。
其他说明：
目标机器的部署方式：nginx  php-fpm  php 脚本。
测试压力机器和目标机器独立部署。

6. 3.2 裸 PHP 性能
最简单的 PHP 脚本。
<?php
require_once './actions/indexAction.php';
$objAction = new indexAction();
$objAction->init();
$objAction->execute();
?>
Acitons/indexAction.php 里面的代码如下
<?php
class indexAction
{
public function execute()
{
echo 'hello, world!';
}
}
?>
通过压力工具测试结果如下：
压力 原生 PHP(cpu idle)
1000QPS 95
2000QPS 90
4000QPS 77
8000QPS 65
1000QPS 54
3.3 裸 PHP 框架性能
为了和 3.2 的对比，基于 bingo2 框架实现了类似的功能。代码如下
<?php
require_once 'Bingo/Controller/Front.php';
$objFrontController = Bingo_Controller_Front::getInstance(array(
'actionDir' => './actions',
));
$objFrontController->dispatch();
?>
压力测试结果如下：
压力 Bingo2(cpu idle)
1000QPS 93
2000QPS 84
4000QPS 67

7. 从该测试结果可以看出：框架虽然有一定的消耗，但对整体的性能来说影响是非常小
的。
3.4 标准 PHP 模块的基准性能
所谓标准 PHP 模块，是指一个 PHP 模块所必须要具体的基本功能：
 路由分发。
 自动加载。
 LOG 初始化&Notice 日志打印。所以的 UI 请求都一条标准的日志。
 错误处理。
 时间校正。
 自动计算每个阶段耗时开销。
 编码识别&编码转化。
 标准配置文件的解析和调用
采用 bingo2 的代码自动生成工具产生标准的测试 PHP 模块：test。
测试结果如下：
压力 Test 模块(cpu idle)
300QPS 96
500QPS 93
800QPS 90
1200QPS 88
1600QPS 84
2000QPS 80
3.5 结论
从测试数据的结论来看，PHP 本身的性能还是可以的。基准性能完全能够达到几千甚至
上 W 的 QPS。至于为什么在大多数的 PHP 模块中表现不佳，其实这个时候更应该去找出系
统的瓶颈点，而不是简单的说 OK，PHP 不行，那我们换 C 来搞吧。 （下一个章节，会通过一
些例子来对比，采用 C 来处理不见得有特别的优势）
通过基准数据，可以得出以下几个具体的结论：
1、 PHP 本身性能也很不错。简单功能下能够达到 5000QPS（50CPU IDLE） ，极限也能
过 W。
2、 PHP 框架本身对性能影响非常有限。 尤其是在有一定业务逻辑和数据交互的情况下，
几乎可以忽略。
3、 一个标准的 PHP 模块，基准性能能够达到 2000QPS（80 cpu idle）
。
4PHP 与 C 性能对比分析
很多时候，大家发现 PHP 模块性能不行的时候，就来一句“ok，我们采用 C 重写吧”。
在公司内，采用 C/C++来写业务逻辑模块的现象到处都有，在前几年甚至几乎全部都是采用

8. C 来写。那时候大家真是一个痛苦：调试难、敏捷不要谈。
那么，本章节要谈论的一个话题就是：C 写的业务逻辑和 PHP 写的业务逻辑模块进行性
能对比，采用真实的数据来说话。
4.1 前提
为什么要特别说出这个前提呢？因为在理想情况下，一个功能采用 PHP 实现，该性能
铁定不可能比理想的 C 写出来好。这个前提需要特别注意。
但为什么还要对比呢？因为在现实情况下， 能写出非常优秀的 C 程序，并且在频繁修改
的情况下还能做到完全高性能的又有几个呢？并且在现实的应用中 C 实现的性能是否真的
全都都比 PHP 要好好几倍呢？这些目前都没有确切的数据来论证。
所以，本章节的对比是基于现实中的情况来进行的，并采用真实数据来说话。
4.2 真实业务模块 PHP 模块 VS C 模块
4.2.1 业务模块介绍
一个真实的案列，该业务模块的流量高达数十亿。该模块的架构图如下：
数据交互 数据模块1
Web服 ...
HTTP请求 业务模块 数据交互
务器
数据交互 数据模块n
图 4、业务模块架构图
该业务模块功能非常简单，上层是 web server，下游是各个数据模块。都是基于 socket
进行数据交互。该业务模块的主要工作模型是：响应 web server 的请求，根据请求从各个
后端数据模块读取相应数据，并根据数据产出最终的 HTML 页面返回给 web 服务器。
为了方便后续介绍，定义 CUI 表示用 C 实现的模块，PHPUI 表示用 PHP 实现的模块。
4.2.2C/C++模块的性能数据结果
09 年，该模块重构选择了一个新的 C/C++框架。当时重构的时候，该模块连接的后端数
据模块规模在 5-7 个。
基于 C/C++的模块，最终测试数据数据分成两个部分：
一、性能对比测试。
基于当时线上压力， 进行真实数据的性能测试。所以当时只测试一个压力数据如下：
压力：210QPS
：84.18
CPU（IDLE）

9. 二、极限性能测试 1。
该测试模型是：CUI 只连接一个核心数据模块，其他数据模块完全关闭。
压力大小 响应次数 cpuidle
300 298.99 82.24
400 394.97 76.55
500 487.31 70.83
600 582.85 65.11
700 688.22 59.36
800 769.29 53.72
900 780.44 48.59
1000 882.77 44.61
1100 986.88 38.37
1200 1095.90 31.59
1300 1148.82 26.44
1400 1171.55 22.86
1500 1269.62 19.04
1600 1282.86 15.99
1700 1225.26 14.55
1800 1293.62 12.17
1900 1261.81 9.66
2000 1343.31 8.69
三、极限性能测试 2。
该测试模型是：CUI 连接后端一个核心数据模块，3 个数据模块，其他数据模块不
连接。
测试后性能数据如下：
压力大小 响应次数 cpuidle
100 99.76 84.98
200 198.63 71.79
300 296.82 58.30
400 317.15 55.62
500 315.40 55.52
4.2.3 PHP 实现模块的性能测试数据
到 11 年，基于 09 年的 CUI 基本上达到了代码不看维护的地步。而且这个时候，CUI 的
极限性能已经不到 600QPS（主要原因是随着项目的发展，后端数据模块的数目增加到 14
个）。据此，决定采用 PHP 方案来重写整个模块，并产出最终的 pbui 模块。
性能测试结果分成两种：
1、PHPUI 连接一个核心模块。测试数据如下：

10. 图 5、PHPUI 性能测试结果 1
2、PHPUI 连接后端所有模块（14 个）。测试性能数据如下：
图 6、PHPUI 性能测试结果 2
4.2.4 数据对比结论
由于 PHPUI 和 CUI 的业务逻辑和测试方法都不完全相同，所以抽取了部分大体能对比的
点进行整理。具体对比数据如下：
对比点 PHPUI CUI 备注
真实压力 200QPS，CPU 80% 210QPS，CPU 84% CUI 连接了 7 个后端。
600QPS，CPU 44% PHPUI 连接了 14 个后端
极限压力 300QPS，CPU 80% 299QPS，CPU82% 都只连接一个后端核心数据模
800QPS，CPU 48% 780QPS，CPU48% 块。
900QPS，CPU41% 1343QPS，CPU8%
从上面的对比数据来看，在真实的业务项目中，PHPUI 的性能并不会比 CUI 差。这个不
是简简单单一个模块来验证的，在部门里面，我们有不少模块都是从 C/C++迁移到 PHP，从
迁移的结果来看，并没有存在质的性能下降，大部分模块迁移后性能指标都是非常接近的。
这个时候就需要思考为什么会这样了？细分来说有两个问题：
1、 为什么在真实业务项目中，PHPUI 的性能并不会比 CUI 差太多？
2、 为什么基准的 PHP 性能这么高，80CPU 的情况下 2000QPS，但到了真实的 PHP 模块中只
能是 200QPS？
其实这两个问题，也可以归结成一种原因：在真实业务项目中，影响性能更多的不是说
采用了什么语言，而是其业务相关的部分，比如说 socket 交互次数，比如说字符串处理，
也比如说网络交互包大小。
OK。那么接下来的关键是找出影响性能的关键因素。

11. 4.2.5 影响 PHP 模块性能的关键因素
从前面分析，我们得出，影响前端 PHP 模块性能的关键因素不是语言本身（是否是
PHP/JAVA/C 都不重要）。那么到底影响 PHP 业务模块性能的关键因素在哪里呢？CPU 耗时是
统计一个项目性能的关键点之一， 考虑到系统中都打印出了系列日志。 通过分析日志中请求
的耗时分布可以大体上看出关键点。
在我们系统中，CPU 耗时重点打印出以下几个方面：
1、 请求总时间。
2、 请求关键函数的性能，其中所有的 socket 交互都有耗时计算。
3、 模版渲染也是好事的一个关键点。
在前面分析中，我们基本上判定 socket 和字符串处理是一个关键点之一，通过数据我
们来验证下。抽取一个模块指定数目的日志，进行综合分析得出以下数据：
关键点 耗时比例 备注
Socket 数据交互 67.15% 关键点
模版渲染 13.07%
其他 19.78%
通过这个可以看出，在一个业务模块中，影响最大的是 socket 数据交互，其次是大量
的字符串处理。具体细分来说是以下几个因素：socket 交互次数、socket 交互包大小、socket
交互响应时间、字符串处理。
4.2.6 结论
通过上述分析，可以得出以下结论：在前端业务模块中，PHP 语言本身不会成为性能瓶
颈。因为影响性能的几个关键因数是：
 网络交互数目。
 网络交互数据大小，包含数据打包解包开销。
 网络交互响应时间。
 大量的字符串处理。
5 最终结论
通过上述三个章节的具体分析，可以得出以下结论：
1、从 PHP 实现原理来看，PHP 属于半编译型语言，并且在各个方面都进行了大量的优
化工作，本身不会存在明显的性能问题。但由于动态语言的特性，决定了 PHP 需要运行在
Zend Engine 虚拟机上，并且在变量查找、函数调用、作用域切换等各个方面需要一些额外
开销。
2、从 PHP 的基准性能来看，PHP 本身不会存在明显的资源消耗，单机 QPS 能够轻松过
W， PHP 框架本身也不会对业务系统的性能带来关键性的影响。
3、从真实的应用场景来看，基于 C 语言实现的模块不见得比基于 PHP 实现的模块性能
高效很多。因为在真实的应用场景中，更多的性能开销在于网络数据交互和字符串处理。语
言方面微小的性能差异不会成为瓶颈。
据此，可以推出：基于 C 语言实现的大部分业务系统都可以考虑迁移到 PHP 上来，一

12. 方面能够快速开发，另外一方面性能也不会存在问题。
最后，关于影响 PHP 性能的关键因素的具体分析和关于语言函数级别 PHP 与 C 的基准
性能对比分析，请关注下文《深入探讨 PHP 性能问题》。
6 参考文档
http://yanbin.org/
https://wiki.php.net/internals/zend_mm
http://blog.xiuwz.com/2011/11/09/php-using-internal-zval/
http://developers.facebook.com/blog/post/358/
https://github.com/facebook/hiphop-php