① php的性能探讨和测试
1.缘起
关于PHP，很多人的直观感觉是PHP是一种灵活的脚本语言，库类丰富，使用简单，安全，非常适合WEB开发，但性能低下。PHP的性能是否真的就如同大家的感觉一样的差呢？本文就是围绕这么一个话题来进陵搏行探讨的。从源码、应用场景、基准性能、对比分析等几个方面深入分析PHP之性能问题，并通过真实的数据来说话。
2.从原理分析PHP性能
从原理分析PHP的性能，主要从以下几个方面：内存管理、变量、函数、运行机制来进行分析。
2.1内存管理
类似Nginx的内存管理方式，PHP在内部也是基于内存池，并且引入内存池的生命周期概念。在内存池方面，PHP对PHP脚本和扩展的所有内存相关操作都进行了托管。对大内存和小内存的管理采用了不同的实现方式和优化，具体可以参考以下文档：
2.2变量
总所周知，PHP是一种弱变量类型的语言，所以在PHP内部，所有的PHP变量都对应成一种类型Zval，其中具体定义如下：
在变量方面，PHP做了大量的优化工作，比如说Reference counting和 on writer机制。这样能够保证内存使用上的优化，并且减少内存拷贝次数（请参考
2.3函数
在PHP内部，所有的PHP函数都回转化成内部的一个函数指针。比如说扩展中函数
ZEND_FUNCTION(my_function);//类似functionmy_function(){}
在内部展开后就会是一个函数
voidzif_my_function(INTERNAL_FUNCTION_PARAMETERS);
voidzif_my_function(intht,
zval*return_value,
zval*this_ptr,
intreturn_value_used,
zend_executor_globals*executor_globals);
从这个角度来看，PHP函数在内部也是对应一个函数指针。
2.4运行机制
在话说PHP性能的时候，很多人都会说“C/C++是编译型，JAVA是半编译型，PHP是解释型”。也就是说PHP是先动态解析再代码运行的，所以从这个角度来看，PHP性能必然很差。
的确，从PHP脚本运行来输出，的确是一个动态解析再代码运行的过程。具体来说，PHP脚本的运行机制如下图所示：
PHP的运行阶段也分成三个阶段：
Parse。语法分析阶段。
Compile。编译产出opcode中间码。
Execute。运行，动态运行进行输出。
所以说，在PHP内部，本身也是存在编译的过程。并且据此产生了大量的opcode cache工具，比如说apc、eacc、xcache等等。这些opcode cache在生产环境基本上在标配。基于opcode cache，能到做到“PHP脚本编译一次，多次运行”的效果。从这点上，PHP就和JAVA的半编译机制非常类似。
所以，从运行机制上来看，PHP的运行模式和JAVA是非常类似的，都是先产生中间码，然后运行在不同虚拟机上。
2.5动态运行
从上面的几个分析来看，PHP在内存管理、变量、函数、运行机制等几个方面都做了大量的工作，所以从原理来看，PHP不应该存在性能尺御祥问题，性能至少也应该和Java比较接近。
这个时候就不得不谈PHP动态语言的特性所带来的性能问题了，由于PHP是动态运行时，所以所有的变量、函数、对象调用、作用域实现等等都是在执行阶段中才确定的。这个从根本上决定了PHP性能中很难改变的一些东西：在C/C++等拆蔽能够在静态编译阶段确定的变量、函数，在PHP中需要在动态运行中确定，也就决定了PHP中间码不能直接运行而需要运行在Zend Engine上。
说到PHP变量的具体实现，又不得不说一个东西了：Hashtable。Hashtable可以说在PHP灵魂之一，在PHP内部广泛用到，包含变量符号栈、函数符号栈等等都是基于hashtable的。
以PHP变量为例来说明下PHP的动态运行特点，比如说代码：
?php
$var=“hello,”;
?
该代码的执行结果就是在变量符号栈（是一个hashtable）中新增一个项
当要使用到该变量时候，就去变量符合栈中去查找（也就是变量调用对出了一个hash查找的过程）。
同样对于函数调用也基本上类似有一个函数符号栈（hashtable）。
其实关于动态运行的变量查找特点，在PHP的运行机制中也能看出一些。PHP代码通过解释、编译后的流程下图：
从上图可以看出，PHP代码在compile之后，产出的了类符号表、函数符号表、和OPCODE。在真正执行的时候，zend Engine会根据op code去对应的符号表中进行查找，处理。
从某种程度上，在这种问题的上，很难找到解决方案。因为这是由于PHP语言的动态特性所决定的。但是在国内外也有不少的人在寻找解决方案。因为通过这样，能够从根本上完全的优化PHP。典型的列子有facebook的hiphop。
2.6结论
从上面分析来看，在基础的内存管理、变量、函数、运行机制方面，PHP本身并不会存在明显的性能差异，但由于PHP的动态运行特性，决定了PHP和其他的编译型语言相比，所有的变量查找、函数运行等等都会多一些hash查找的CPU开销和额外的内存开销，至于这种开销具体有多大，可以通过后续的基准性能和对比分析得出。
因此，也可以大体看出PHP不太适合的一些场景：大量计算性任务、大数据量的运算、内存要求很严格的应用场景。如果要实现这些功能，也建议通过扩展的方式实现，然后再提供钩子函数给PHP调用。这样可以减低内部计算的变量、函数等系列开销。
3.基准性能
对于PHP基准性能，目前缺少标准的数据。大多数同学都存在感性的认识，有人认为800QPS就是PHP的极限了。此外，对于框架的性能和框架对性能的影响很没有响应的权威数字。
本章节的目的是给出一个基准的参考性能指标，通过数据给大家一个直观的了解。
具体的基准性能有以下几个方面：
1.裸PHP性能。完成基本的功能。
2.裸框架的性能。只做最简单的路由分发，只走通核心功能。
3.标准模块的基准性能。所谓标准模块的基准性能，是指一个具有完整服务模块功能的基准性能。
3.1环境说明
测试环境：
Uname -aPnux db-forum-test17.db01..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/Pnux
Red Hat Enterprise Pnux 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 (cP) (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脚本。
测试压力机器和目标机器独立部署。
3.2裸PHP性能
最简单的PHP脚本。
?php
require_once‘./actions/indexAction.php’;
$objAction=newindexAction();
$objAction-init();
$objAction-execute();
?
Acitons/indexAction.php里面的代码如下
?php
classindexAction
{
pubPcfunctionexecute()
{
echo‘hello,world!’;
}
}
?
通过压力工具测试结果如下：
3.3裸PHP框架性能
为了和3.2的对比，基于bingo2框架实现了类似的功能。代码如下
?php
require_once‘Bingo/Controller/Front.php’;
$objFrontController=Bingo_Controller_Front::getInstance(array(‘actionDir’=‘./actions’,));
$objFrontController-dispatch();
压力测试结果如下：
从该测试结果可以看出：框架虽然有一定的消耗，但对整体的性能来说影响是非常小的。
3.4标准PHP模块的基准性能
所谓标准PHP模块，是指一个PHP模块所必须要具体的基本功能：
路由分发。
自动加载。
LOG初始化Notice日志打印。所以的UI请求都一条标准的日志。
错误处理。
时间校正。
自动计算每个阶段耗时开销。
编码识别编码转化。
标准配置文件的解析和调用
采用bingo2的代码自动生成工具产生标准的测试PHP模块：test。
测试结果如下：
3.5结论
从测试数据的结论来看，PHP本身的性能还是可以的。基准性能完全能够达到几千甚至上W的QPS。至于为什么在大多数的PHP模块中表现不佳，其实这个时候更应该去找出系统的瓶颈点，而是简单的说OK，PHP不行，那我们换C来搞吧。（下一个章节，会通过一些例子来对比，采用C来处理不见得有特别的优势）
通过基准数据，可以得出以下几个具体的结论：
1.PHP本身性能也很不错。简单功能下能够达到5000QPS，极限也能过W。
2.PHP框架本身对性能影响非常有限。尤其是在有一定业务逻辑和数据交互的情况下，几乎可以忽略。
3.一个标准的PHP模块，基准性能能够达到2000QPS（80 cpu idle）。
4.对比分析
很多时候，大家发现PHP模块性能不行的时候，就来一句“ok，我们采用C重写吧”。在公司内，采用C/C++来写业务逻辑模块的现象到处都有，在前几年甚至几乎全部都是采用C来写。那时候大家写的真是一个痛苦：调试难、敏捷不要谈。
② php运行机制是什么
PHP是一种纯解释型在服务端执行的可以内嵌HTML的脚本语言，尤其适合开发Web应用程序。
请求一个 PHP 脚本时，PHP 会读取该脚本，并将其编译为 Zend 操作码，这是要执行的代码的一种二进制表示形式。随后，此操作码由 PHP 执行并丢弃。 PHP脚本在每次被解释时进行初始化，在解释完毕后终止运行。这种运行是互相独立的，每一次请求都会创建一个单独的进程或线程，来解释相应的页面文件。页面创建的变量和其他对象，都只在当前的页面内部可见，无法跨越页面访问。在终止运行后，页面中申请的、没有被代码显式释放的外部资源，包括内存、数据库连接、文件句柄、Socket连接等，都会被强行释放。也就是说，PHP无法在语言级别上实现直接访问跨越页面的变量，也无法创建驻留内存的对象。
PHP这种独特的工作模型的优势在于，基本上解决了令人头疼的资源泄漏问题。Web应用的特点是大量的、短时间的并发处理，对各种资源的申请和释放工作非常频繁，很容易导致泄漏甚至崩溃。PHP的运行机制决定它不存在常规的崩溃问题(顶多连接超时脚本停止执行)，可以说PHP是较稳定的Web应用。但是，这种机制的缺点也非常明显。最直接的后果是，PHP在语言级别无法实现跨页面的缓冲机制。这种缓冲机制缺失造成的影响，可以分成两个方面：
一是对象的缓冲。众所周知，很多设计模式都依赖于对象的缓冲机制，创建和销毁对象是很费时间的，因为创建一个对象要获取内存资源或者其它更多资源，对于需要频繁应付大量并发的服务端软件更是如此。因此，对象缓冲的缺失，理论上会极大地降低速度。应尽可能减少创建和销毁对象的次数来提高服务程序的效率，由于 PHP目前还不支持多线程，也就无法像Java一样通过线程池调度来弥补这一缺陷；但可以使用第三方软件如Memcachd来实现PHP的对象缓冲机制，达到减少对象创建和销毁的时间来提高服务程序的效率。Memcachd将PHP编译后的 操作码缓存并在内存中保存这个操作码，并在下一次调用该页面时重用它，这会节省很多时间。比较常用的缓存还有有 eAccelerator，另一种流行的 eAccelerator 替代工具是 Alternative PHP Cache(APC)。
二是数据库连接的缓冲。对于MySQL，PHP提供了一种内置的数据库缓冲机制，即用mysql_pconnect()代替mysql_connect() 来打开数据库而已。PHP会自动回收被废弃的数据库连接，以供重复使用。在实际应用中，这种持久性数据库连接往往会导致数据库连接的伪泄漏现象：在某个时间，并发的数据库连接过多，超过了MySQL的最大连接数，从而导致新的进程无法连接数据库。但是过一段时间，当并发数减少时，PHP会释放掉一些连接，网站又会恢复正常。出现这种现象的原因是，当使用pconnect时，Apache 的httpd进程会不释放connect，而当Apache的httpd进程数超过了mysql的最大连接数时，就会出现无法连接的情况。因此，需要小心地调整Apache和Mysql的配置，以使Apache的httpd进程数不会超出MySQL的最大连接数。笔者经过实践，在PHP5和 Oracle10g的连接中，由于频于数据库连接，有时候还会出现数据库丢失连接的情况(Oracle官方有针对PHP的增强包，不知是否可以解决此问题，笔者未试)。
PHP的工作模型即是缺点也是优势，从本质上说，这就是PHP 的独特之处。
若以FastCGI模式运行php,解析php.ini、载入全部扩展并重初始化全部数据结构这些都只在进程启动时发生一次。一个额外的好处是，持续数据库连接可以工作。Nginx+PHP(FastCGI)是个不错的选择。
③ php在web上运行是多进程还是单进程
php在web上运行是单进程的，具体原因如下：
1、PHP是一个单线程的脚本开发语言，它常在Web开发及系统集成中出现。
PHP是单进程单线程的，当处理复杂的业务的时候我们会发现他串行执行命令的时候CPU、磁盘、内存等利用的都很低有很多时候都是在排队等待，有的时候我们想并发的让他去执行一批任务然后一起拿解决结果是一件很痛苦的事情（自己用pthread或者其他方式才能解决，但是这很痛苦）开发语言一直在升级变化适应需要。另外，可以考虑通讯使用Swoole。
2、解决方案如下：
分前后端，前端可以通过消息中间件，同步、异步 调用一个或多个接口。但是socket的扩展确确实实不咋好用。不是普通小企业能做的出来的。
④ 如何获得php当前的运行模式
PHP 获取当前运行模式,使用php_sapi_name函数即可；示例如下：
<?php
$mod=php_sapi_name();
echo$mod;
//apache2handler
//PHP有多种运行模式，例如：apache、apache2filter、apache2handler、caudium、cgi
//cgi-fcgi、cli、cli-server、continuity、embed、fpm-fcgi等等。?>
⑤ 请问php在apache下运行有几种模式,区别是什么该怎样设置,谢谢
Windows 下有两种方法使 PHP 工作于 Apache 2.0.x 之中。一种是 使用 CGI 可执行程序，另一种是适用 Apache 模块的 DLL。不管哪种都需要编辑 httpd.conf 来配置 Apache 支持 PHP 并重新启动服务器。
注: 记住在 Windows 下给 Apache 的配置文件中加入路径值的时候，所有的反斜线例如 c:\directory\file.ext 必须转换成正斜线，如 c:/directory/file.ext。
以 CGI 方式安装
需要将以下三行加入到 Apache 的 httpd.conf 配置文件中以设定 CGI： 例子 6-5. PHP 在 Apache 2.0 中的 CGI 方式
ScriptAlias /php/ "c:/php/"
AddType application/x-httpd-php .php
# 对 PHP 4 用这行
Action application/x-httpd-php "/php/php.exe"
# 对 PHP 5 用这行
Action application/x-httpd-php "/php/php-cgi.exe"
警告
如果使用 CGI 方式安装，则服务器对于某些可能的攻击是开放的。请阅读 CGI 安全一章以学习如何防御这些攻击。
以 Apache 模块方式安装
需要将以下两行加入到 Apache 的 httpd.conf 配置文件中以设定 Apache 2.0 的 PHP 模块： 例子 6-6. PHP 在 Apache 2.0 中的模块方式
# 对 PHP 4 用这两行：
LoadMole php4_mole "c:/php/php4apache2.dll"
# 别忘了从 sapi 目录中把 php4apache2.dll 拷贝出来！
AddType application/x-httpd-php .php
# 对 PHP 5 用这两行：
LoadMole php5_mole "c:/php/php5apache2.dll"
AddType application/x-httpd-php .php
# 配置 php.ini 的路径
PHPIniDir "C:/php"
注: 记得用自己 PHP 实际所在的路径替换掉上例中的 c:/php/。要留意在 LoadMole 指令中用的是 php4apache2.dll 或 php5apache2.dll，而不是 php4apache.dll 或 php5apache.dll，后者是设计用于 Apache 1.3.x 的。
注: 如果要使用内容协商机制，请阅读有关 FAQ。
警告
不要在安装中混合使用来自不同 PHP 版本的 DLL。使用下载回来的 PHP 版本中所提供的 DLL 和扩展库是唯一选择。