Heim > php教程 > php手册 > 大话PHP之性能

大话PHP之性能

WBOY
Freigeben: 2016-06-06 19:46:06
Original
948 Leute haben es durchsucht

1缘起 关于PHP,很多人的直观感觉是PHP是一种灵活的脚本语言,库类丰富,使用简单,安全,非常适合WEB开发,但性能低下。PHP的性能是否真的就如同大家的感觉一样的差呢?本文就是围绕这么一个话题来进行探讨的。从源码、应用场景、基准性能、对比分析等几个

1缘起

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

2从原理分析PHP性能

从原理分析PHP的性能,主要从以下几个方面:内存管理、变量、函数、运行机制、网络模型来进行分析。

2.1内存管理

类似Nginx的内存管理方式,PHP在内部也是基于内存池,并且引入内存池的生命周期概念。在内存池方面,PHP对PHP脚本和扩展的所有内存相关操作都进行了托管。对大内存和小内存的管理采用了不同的实现方式和优化,具体可以参考以下文档:http://www.laruence.com/2011/11/09/2277.html。在内存分配和回收的生命周期内,PHP采用一次初始化申请+动态扩容+内存标识回收机制,并且在每次请求结束后直接对内存池进行重新mask。

2.2变量

总所周知,PHP是一种弱变量类型的语言,所以在PHP内部,所有的PHP变量都对应成一种类型Zval,其中具体定义如下:

大话PHP之性能

图一、PHP变量

在变量方面,PHP做了大量的优化工作,比如说Reference counting和copy on writer机制。这样能够保证内存使用上的优化,并且减少内存拷贝次数(请参考http://blog.xiuwz.com/2011/11/09/php-using-internal-zval/)。在数组方面,PHP内部采用高效的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脚本的运行机制如下图所示:

大话PHP之性能

图二、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的动态运行特点,比如说代码:

$var = “hello, blog.xiuwz.com”;

?>

该代码的执行结果就是在变量符号栈(是一个hashtable)中新增一个项

大话PHP之性能

当要使用到该变量时候,就去变量符合栈中去查找(也就是变量调用对出了一个hash查找的过程)。

同样对于函数调用也基本上类似有一个函数符号栈(hashtable)。

其实关于动态运行的变量查找特点,在PHP的运行机制中也能看出一些。PHP代码通过解释、编译后的流程下图:
大话PHP之性能

图3、PHP运行实例

从上图可以看出,PHP代码在compile之后,产出的了类符号表、函数符号表、和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本身并不会存在明显的性能差异,但由于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框架。

其他说明:

目标机器的部署方式:大话PHP之性能脚本。

测试压力机器和目标机器独立部署。

3.2裸PHP性能

最简单的PHP脚本。

require_once ‘./actions/indexAction.php’;

$objAction = new indexAction();

$objAction->init();

$objAction->execute();

?>

Acitons/indexAction.php里面的代码如下

class indexAction

{

public function execute()

{

echo ‘hello, world!’;

}

}

?>

通过压力工具测试结果如下:

大话PHP之性能

3.3裸PHP框架性能

为了和3.2的对比,基于bingo2框架实现了类似的功能。代码如下

require_once ‘Bingo/Controller/Front.php’;

$objFrontController = Bingo_Controller_Front::getInstance(array(

‘actionDir’ => ‘./actions’,

));

$objFrontController->dispatch();

?>

压力测试结果如下:

大话PHP之性能

从该测试结果可以看出:框架虽然有一定的消耗,但对整体的性能来说影响是非常小的

3.4标准PHP模块的基准性能

所谓标准PHP模块,是指一个PHP模块所必须要具体的基本功能:

●路由分发。

●自动加载。

●LOG初始化&Notice日志打印。所以的UI请求都一条标准的日志。

●错误处理。

●时间校正。

●自动计算每个阶段耗时开销。

●编码识别&编码转化。

●标准配置文件的解析和调用

采用bingo2的代码自动生成工具产生标准的测试PHP模块:test。

测试结果如下:

大话PHP之性能

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++来写业务逻辑模块的现象到处都有,在前几年甚至几乎全部都是采用C来写。那时候大家写的真是一个痛苦:调试难、敏捷不要谈。

那么,本章节要谈论的一个话题就是:C写的业务逻辑和PHP写的业务逻辑模块进行性能对比,采用真实的数据来说话。

4.1前提

为什么要特别说出这个前提呢?因为在理想情况下,一个功能采用PHP实现,该性能铁定不可能比理想的C写出来好。这个前提需要特别注意。

但为什么还要对比呢?因为在现实情况下,能写出非常优秀的C程序,并且在频繁修改的情况下还能做到完全高性能的又有几个呢?并且在现实的应用中C实现的性能是否真的全都都比PHP要好好几倍呢?这些目前都没有确切的数据来论证。

所以,本章节的对比是基于现实中的情况来进行的,并采用真实数据来说话。

4.2 真实业务模块PHP模块 VS C模块

4.2.1业务模块介绍

一个真实的案列,该业务模块的流量高达数十亿。该模块的架构图如下:

大话PHP之性能

图4、业务模块架构图

该业务模块功能非常简单,上层是web server,下游是各个数据模块。都是基于socket进行数据交互。该业务模块的主要工作模型是:响应web server的请求,根据请求从各个后端数据模块读取相应数据,并根据数据产出最终的HTML页面返回给web服务器

为了方便后续介绍,定义CUI表示用C实现的模块,PHPUI表示用PHP实现的模块。

4.2.2C/C++模块的性能数据结果

09年,该模块重构选择了一个新的C/C++框架。当时重构的时候,该模块连接的后端数据模块规模在5-7个

基于C/C++的模块,最终测试数据数据分成两个部分:

一、性能对比测试。

基于当时线上压力,进行真实数据的性能测试。所以当时只测试一个压力数据如下:

压力:210QPS

CPU(IDLE):84.18

二、极限性能测试1。

该测试模型是:CUI只连接一个核心数据模块,其他数据模块完全关闭。

大话PHP之性能

三、极限性能测试2。

该测试模型是:CUI连接后端一个核心数据模块,3个数据模块,其他数据模块不连接。

测试后性能数据如下:

大话PHP之性能

4.2.3 PHP实现模块的性能测试数据

到11年,基于09年的CUI基本上达到了代码不看维护的地步。而且这个时候,CUI的极限性能已经不到600QPS(主要原因是随着项目的发展,后端数据模块的数目增加到14个)。据此,决定采用PHP方案来重写整个模块,并产出最终的pbui模块。

性能测试结果分成两种:

1、PHPUI连接一个核心模块。测试数据如下:

大话PHP之性能

图5、PHPUI性能测试结果1

2、PHPUI连接后端所有模块(14个)。测试性能数据如下:

大话PHP之性能

图6、PHPUI性能测试结果2

4.2.4数据对比结论

由于PHPUI和CUI的业务逻辑和测试方法都不完全相同,所以抽取了部分大体能对比的点进行整理。具体对比数据如下:

大话PHP之性能

从上面的对比数据来看,在真实的业务项目中,PHPUI的性能并不会比CUI差。这个不是简简单单一个模块来验证的,在部门里面,我们有不少模块都是从C/C++迁移到PHP,从迁移的结果来看,并没有存在质的性能下降,大部分模块迁移后性能指标都是非常接近的。

这个时候就需要思考为什么会这样了?细分来说有两个问题:

1、   为什么在真实业务项目中,PHPUI的性能并不会比CUI差太多?

2、  为什么基准的PHP性能这么高,80CPU的情况下2000QPS,但到了真实的PHP模块中只能是200QPS?

其实这两个问题,也可以归结成一种原因:在真实业务项目中,影响性能更多的不是说采用了什么语言,而是其业务相关的部分,比如说socket交互次数,比如说字符串处理,也比如说网络交互包大小

OK。那么接下来的关键是找出影响性能的关键因素。

4.2.5影响PHP模块性能的关键因素

从前面分析,我们得出,影响前端PHP模块性能的关键因素不是语言本身(是否是PHP/JAVA/C都不重要)。那么到底影响PHP业务模块性能的关键因素在哪里呢?CPU耗时是统计一个项目性能的关键点之一,考虑到系统中都打印出了系列日志。通过分析日志中请求的耗时分布可以大体上看出关键点。

在我们系统中,CPU耗时重点打印出以下几个方面:

1、  请求总时间。

2、  请求关键函数的性能,其中所有的socket交互都有耗时计算。

3、  模版渲染也是好事的一个关键点。

在前面分析中,我们基本上判定socket和字符串处理是一个关键点之一,通过数据我们来验证下。抽取一个模块指定数目的日志,进行综合分析得出以下数据:

大话PHP之性能

通过这个可以看出,在一个业务模块中,影响最大的是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上来,一方面能够快速开发,另外一方面性能也不会存在问题。

最后,关于影响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



原文来源:http://stblog.baidu-tech.com/?p=1343
Verwandte Etiketten:
Quelle:php.cn
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Empfehlungen
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage