PHP沉思录

sulpha

                                工作模型
　　 PHP的工作模型非常特殊。从某种程度上说，PHP和ASP、ASP.NET、JSP/Servlet等流行的Web技术，有着本质上的区别。
　
　 以Java为例，Java在Web应用领域，有两种技术：Java Servlet和JSP（Java Server Page）。Java
Servlet是一种特殊类型的Java程序，它通过实现相关接口，处理Web服务器发送过来的请求，完成相应的工作。JSP在形式上是一种类似于PHP
的脚本，但是事实上，它最后也被编译成Servlet。
也就是说，在Java解决方案中，JSP和Servlet是作为独立的Java应用
程序执行的，它们在初始化之后就驻留内存，通过特定的接口和Web服务器通信，完成相应工作。除非被显式地重启，否则它们不会终止。因此，可以在JSP和
Servlet中使用各种缓存技术，例如数据库连接池。
　　 ASP.NET的机制与此类似。至于ASP，虽然也是一种解释型语言，但是仍然提供了Application对象来存放应用程序级的全局变量，它依托于ASP解释器在IIS中驻留的进程，在整个应用程序的生命期有效。
　
　
PHP却完全不是这样。作为一种纯解释型语言，PHP脚本在每次被解释时进行初始化，在解释完毕后终止运行。这种运行是互相独立的，每一次请求都会创建一
个单独的进程或线程，来解释相应的页面文件。页面创建的变量和其他对象，都只在当前的页面内部可见，无法跨越页面访问。
在终止运行后，页面中申请的、没有被代码显式释放的外部资源，包括内存、数据库连接、文件句柄、Socket连接等，都会被强行释放。
　　 也就是说，PHP无法在语言级别直接访问跨越页面的变量，也无法创建驻留内存的对象。见下例：
　　
　　 ";
　　 TestStaticVar();
　　 ?>
　　
　
　
在这个例子中，定义了一个名为StaticVarTester的类，它仅有一个公共的静态成员$StaticVar，并被初始化为0。然后，在
TestStaticVar()函数中，对StaticVarTester :: $StaticVar进行累加操作，并将它打印输出。
　　
熟悉Java或C++的开发者对这个例子应该并不陌生。$StaticVar作为StaticVarTester类的一个静态成员，只在类被装载时进行初
始化，无论StaticVarTester类被实例化多少次，$StaticVar都只存在一个实例，而且不会被多次初始化。因此，当第一次调用
TestStaticVar()函数时，$StaticVar进行了累加操作，值为1，并被保存。第二次调用TestStaticVar()函
数，$StaticVar的值为2。
　　 打印出来的结果和我们预料的一样：
　　
　　 StaticVarTester :: StaticVar = 1
　　 StaticVarTester :: StaticVar = 2
　　
　　 但是，当浏览器刷新页面，再次执行这段代码时，不同的情况出现了。在Java或C++里面，$StaticVar的值会被保存并一直累加下去，我们将会看到如下的结果：
　　
　　 StaticVarTester :: StaticVar = 3
　　 StaticVarTester :: StaticVar = 4
　　 …
　　
　　 但是在PHP中，由于上文叙及的机制，当前页面每次都解释时，都会执行一次程序初始化和终止的过程。也就是说，每次访问时，StaticVarTester都会被重新装载，而下列这行语句
　　
　　 public static $StaticVar = 0;
　　
　
　
也会被重复执行。当页面执行完成后，所有的内存空间都会被回收，$StaticVar这个变量(连同整个StaticVarTester类)也就不复存
在。因此，无论刷新页面多少次，$StaticVar变量都会回到起点：先被初始化为0，然后在TestStaticVar()函数调用中被累加。所以，
我们看到的结果永远是这个：
　　
　　 StaticVarTester :: StaticVar = 1
　　 StaticVarTester :: StaticVar = 2
PHP这种独特的工作模型的优势在于，基本上解决了令人头疼的资源泄漏问题。Web应用的特点是大量的、短时间的并发处理，对各种资源的申请和释放工作非常频繁，很容易导致泄漏。
同
时，大量的动态html脚本的存在，使得追踪和调试的工作都非常困难。PHP的运行机制，以一种非常简单的方式避免了这个问题，同时也避免了将程序员带入
到繁琐的缓冲池和同步等问题中去。在实践中，基于PHP的应用往往比基于Java或.NET的应用更加稳定，不会出现由于某个页面的BUG而导致整个站点
崩溃的问题。
(相比之下，Java或.NET应用可能因为缓冲池崩溃或其他的非法操作，而导致整个站点崩溃。)后果是，即使PHP程序员水
平不高，也无法写出使整个应用崩溃的代码。PHP脚本可以一次调用极多的资源，从而导致页面执行极为缓慢，但是执行完毕后所有的资源都会被释放，应用仍然
不会崩溃。
甚至即使执行了一个死循环，也会在30秒（默认时间）后因为超时而中止。从理论上来说，基于PHP的应用是不太可能崩溃的，因为它的运行机制决定它不存在常规的崩溃这个问题。在实践中，很多开发者也认为PHP是最稳定的Web应用。
但是，这种机制的缺点也非常明显。最直接的后果是，PHP在语言级别无法实现跨页面的缓冲机制。这种缓冲机制缺失造成的影响，可以分成两个方面：
　
　
一是对象的缓冲。如我们所知，很多设计模式都依赖于对象的缓冲机制，对于需要频繁应付大量并发的服务端软件更是如此。因此，对象缓冲的缺失，理论上会极大
地降低速度。但是，由于PHP本身的定位和工作机制等原因，它在实际工作中的速度非常快。就作者自己的经验来看，在小型的Web应用中，PHP至少不比
Java慢。
在大型的应用中，为了榨干每一分硬件资源，即使PHP本身足够快，一个优秀的对象缓冲机制仍然是必要的。在这种情况下，可以使
用第三方的内存缓冲软件，如Memcached。由于Memcached本身的优异特性（高性能，支持跨服务器的分布式存储，和PHP的无缝集成等），在
大型的PHP应用中，Memcached几乎已经成为不可或缺的基础设施了。比起使用PHP语言自己实现对象缓冲来，这种第三方解决方案似乎更好一些。
　　 二是数据库连接的缓冲。对MySQL，PHP提供了一种内置的数据库缓冲机制，使用起来非常简单，程序员需要做的只是用mysql_pconnect()代替mysql_connect()来打开数据库而已。
PHP会自动回收被废弃的数据库连接，以供重复使用。具有讽刺意味的是，在实际应用中，这种持久性数据库连接往往会导致数据库连接的伪泄漏现象：在某个时间，并发的数据库连接过多，超过了MySQL的最大连接数，从而导致新的进程无法连接数据库。
但
是过一段时间，当并发数减少时，PHP会释放掉一些连接，网站又会恢复正常。出现这种现象的原因是，当使用pconnect时，Apache的httpd
进程会不释放connect，而当Apache的httpd进程数超过了mysql的最大连接数时，就会出现无法连接的情况。因此，需要小心地调整
Apache和Mysql的配置，以使Apache的httpd进程数不会超出MySQL的最大连接数。在某些情况下，一些有经验的PHP程序员宁可继续
使用mysql_connect()，而不是mysql_pconnect()。
　　
就作者所知，在PHP未来的roadmap中，对于工作模型这一部分，没有根本性的变动。这是PHP的缺点，也是PHP的优势，从本质上说，这就是PHP
的独特之处。因此，我们很难期待PHP在近期内会对这一问题做出重大的改变。但是，在对待这个问题带来的一系列后果时，我们必须谨慎应对。
　　
　　 数据库访问接口
　
　
长期以来，PHP都缺乏一个象ADO或JDBC那样的统一的数据库访问接口。PHP在访问不同的数据库时，使用不同的专门API。例如，使用
mysql_connect函数连接MySQL，使用ora_logon函数连接Oracle。平心而论，这种方式并没有象我们想象的那样麻烦。
在真实项目中，把系统从一种数据库完全迁移到另一种数据库的要求是比较少见的，特别是对于LAMP这样的小型项目而言。而且，只要将访问数据库的代码进行了良好的封装，迁移的工作量也会较少。另外，使用专门API，在效率上多少会有一些优势。
　　 虽然如此，PHP的开发人员仍然在努力构建PHP的统一的数据库访问接口。从PHP 5.1开始，PHP的发行包内置了PDO（PHP Data Objects，PHP数据对象）。PDO具有如下特性：
　　
　　  统一的数据库访问接口。PDO为访问不同的数据库提供了统一的接口，并且能够通过切换数据库驱动程序，方便地支持各种流行的数据库。
　　  面向对象。PDO完全基于PHP 5的对象机制，因此区别于基于过程的专用API。
　　  高性能。PDO的底层用C编写，比起用纯PHP开发的其他类似解决方案，有更高的性能。
　　
　　 一个典型的PDO应用如下例：
　　
　　 $pdo = new PDO("mysql:host=localhost;dbname=justtest", " mysql_user ", " mysql_password");
　　 $query = "SELECT id, username FROM userinfo ORDER BY ID";
　　 foreach ($pdo->query($query) as $row) {
　　 echo $row['id']." | ".$row['username']."";
　　 }
PME模型
在大规模的程序设计中，组件（component）已经成为一种非常流行的技术。常见的组件技术都基于PME模型，即属性（Property）、方法（Method）和事件（Event）。
基于PME的组件技术可以方便地实现IoC（Inversion of Control，控制反转），是从IDE的plugin到应用服务器的“热发布”等许多技术的基础。
PHP从版本5开始，大大完善了对OO的支持，以前不能被应用的许多pattern现在都可以在PHP5中实现。因此，是否能够实现基于PHP的组件技术，也就成了一个值得讨论的问题。
下面对PHP对于PME模型的支持，逐一进行讨论：
 属性（Property）
PHP并不支持类似Delphi或者C#的property语法，但这并不是问题。Java也不支持property语法，但是通过getXXX()和setXXX()的命名约定，同样可以支持属性。
PHP也可以通过这一方式来支持属性。但是，PHP提供了另一种也许更好的方法，那就是__set()和__get()方法。
在PHP中，每一个class都会自动继承__set()和__get()方法。它们的定义如下：
void __set ( string name, mixed value )
mixed __get ( string name )
这两个方法将在下列情况下被触发：当程序访问一个当前类没有显式定义的属性时。在这个时候，被访问的属性名称作为参数被传入相应的方法。任何类都可以重载__set()和__get()方法，以实现自己的功能。
如下例：
class PropertyTester {
public function __get($PropName) {
echo "Getting Property $PropNamen";
}
public function __set($PropName, $Value) {
echo "Setting Property $PropName to '$Value'n";
}
}
$Prop = new PropertyTester();
$Prop->Name;
$Prop->Name = "some string";
类
PropertyTester重载了__set()和__get()方法，为了测试，仅仅将参数打印输出，没有做更多的工作。测试代码创建了
PropertyTester类的实例，并试图读写它并不存在的一个属性Name。此时，__set()和__get()相继被调用，并打印出相关参数。
它的输出结果如下：
Getting Property Name
Setting Property Name to 'some string'
基于这种机制，我们可以将属性的值放在一个private的List中，在读写属性时，通过重载__set()和__get()方法，读写List中的属性值。
但
是，__set()和__get()方法的有趣之处远不止及。通过这两个方法，可以实现动态属性，也就是不在程序中显式定义，而是在运行时动态生成的属
性。只要想想这种技术在OR
Mapping中的作用就能够明白它的重要性了。配合__call()方法（用于实现动态方法，在下一节中详述），它能够取代丑陋的代码生成器（code
generator）的大部分功能。
 方法（Method）
PHP对方法的支持比较简单，没有太多可以讨论的。值得一提的是，PHP从版本5开始支持类的静态方法（static method），这使得程序员再也不用无谓地增加许多全局函数了。
 事件（Event）
事件也许是PHP遇到的最复杂的问题。PHP并没有在语法层面提供对事件的支持，我们只能考虑通过别的途径来实现。因此，我们需要先对事件的概念和其他语言对事件的实现方式进行讨论。
事件模型可以简述如下：充当事件触发者的代码本身并不处理事件，而仅仅是在事件发生时，把程序控制权转交给事件的处理者，在事件处理完成后，再收回控制权。事件触发者本身并不知道事件将会被如何处理，在大多数情况下，事件触发者的代码要先于事件处理者的代码被完成。
在
传统的面向过程的语言（例如C或者PASCAL）中，事件可以通过函数指针来实现。具体来说，事件触发者定义一个函数指针，这个函数指针可以在以后被指向
某个处理事件的函数。在事件发生时，调用该函数指针指向的处理函数，并将事件的上下文作为参数传入。处理完成后，控制权再回到事件触发者。
在面向对象的语言中，方法指针（指向某个类的方法的指针）取代了函数指针。以Delphi为例，事件处理的例子如下：
type
TNotifyEvent = procedure(Sender: TObject) of object;
TMainForm = class(TForm)
procedure ButtonClick(Sender: TObject);
…
End;
Var
MainForm: TMainForm;
OnClick: TNotifyEvent;
…
可
以看出，TNotifyEvent被定义为所谓的过程类型（Procedural
Type），事实上就是一个方法指针。TMainForm的ButtonClick方法是一个事件处理者，符合TNotifyEvent的签名。
OnClick是一个事件触发者。在实际使用时，通过如下代码：
OnClick := MainForm.ButtonClick;
将MainForm.ButtonClick方法绑定到了OnClick事件。当OnClick事件触发时，MainForm.ButtonClick方法将被调用，并且将Sender(触发事件的组件对象)作为参数传入。
回到PHP，由于PHP不支持指针，因此无法使用函数指针这一技术。但是，PHP支持所谓的“函数变量”，可以把函数赋予某个变量，其作用类似于函数指针。如下例：
function EventHandler($Sender) {
echo "Calling EventHandler(), arv = $Sendern";
}
$Func = 'EventHandler';
$Func('Sender Name');
由
于PHP是一种动态语言，变量可以为任何类型，所以无须先定义函数指针的类型作为事件的签名。直接定义了一个函数EventHandler作为事件处理
者，然后将它赋予变量$Func（注意直接使用了字符串形式的函数名），最后触发该事件，并将一个字符串“Sender
Name”传给它作为参数。输出的结果是：
Calling EventHandler(), arv = Sender Name
同样地，PHP也提供了类似方法指针的机制。如下例：
Class EventHandler {
public function DoEvent($Sender) {
echo "Calling EventHandler.DoEvent(), arg = $Sendern";
}
}
$EventHanler = new EventHandler();
$HandlerObject = $EventHanler;
$Method = 'DoEvent';
$HandlerObject->$Method('Sender Name');
由于PHP中没有能够直接引用对象方法的变量，因此需要使用两个变量来间接实现：$HandlerObject指向对象，$Method指向对象方法。通过$HandlerObject->$Method方式的调用，可以动态地指向任何对象方法。
为了使代码更加优雅和更适合复用，可以定义一个专门的类NotifyEvent，并使用一段新的调用代码：
final class NotifyEvent {
private $HandlerObject;
private $Method;
public function __construct($HandlerObject, $Method) {
$this->HandlerObject = $HandlerObject;
$this->Method = $Method;
}
public function Call($Sender) {
$Method = $this->Method;
$this->HandlerObject->$Method($Sender);
}
}
$EventHanler = new EventHandler();
$NotifyEvent = new NotifyEvent($EventHanler, 'DoEvent');
$NotifyEvent->Call('Sender Name');
NotifyEvent类定义了两个私有变量$HandlerObject和$Method，分别指向事件处理者对象和处理方法。在构造函数中对这两个变量赋值，再通过Call方法来调用。
熟
悉C#的读者可以发现，NotifyEvent类与C#中的Delegate十分类似。Delegate超过NotifyEvent的地方在于支持多播
（Multicast），也就是一个事件可以绑定多个事件处理者。只要事件触发者自己维护一个NotifyEvent对象数组，支持多播也不是一件难事。
至此，PHP对事件的支持已经得到了比较圆满的解决。但是，人的求知欲是无穷无尽的。还有没有可能通过其他的方式来实现事件呢？
除了方法指针，接口（interface）也可以用于实现事件。在Java中，这种技术被广泛应用。其核心思想是，将事件处理者的处理函数定义抽象为一个接口（相当于函数指针的签名），事件触发者针对这个接口编程，事件处理者则实现这个接口。
这种方式的好处在于，不需要语言支持函数指针或方法指针，让代码显得更加清晰和优雅，缺陷在于，实现同一种功能，要使用更多的代码。如下例：
interface IEventHandler {
public function DoEvent($Sender, $Arg);
}
class EventHanlerAdapter implements IEventHandler {
public function DoEvent($Sender, $Arg) {
echo "Calling EventHanlerAdapter.DoEvent(), Sender = $Sender, arg = $Argn";
}
}
class EventRaiser {
private $EventHanlerVar;
public function __construct($EventHanlerAdapter) {
$this->EventHanlerVar = $EventHanlerAdapter;
}
public function RaiseEvent() {
if ($this->EventHanlerVar != null) {
$this->EventHanlerVar->DoEvent($this, 'some string');
}
}
public function __tostring() {
return 'Object EventRaier';
}
}
$EventHanlerAdapter = new EventHanlerAdapter();
$EventRaiser = new EventRaiser($EventHanlerAdapter);
$EventRaiser->RaiseEvent();
首
先定义了一个接口IEventHandler，它包含了方法的签名。EventHanlerAdapter类作为事件处理者，实现了这个接口，并提供了相
应的处理方法。EventRaiser类作为事件触发者，针对$EventHanlerVar变量（它应该是IEventHandler接口类型，但是在
PHP中不用显式定义）编码。
在实际应用中，将EventHanlerAdapter的实例作为参数赋予传给EventRaiser类的构造函数，当事件发生时，相应的处理方法将被调用。输出结果如下：
Calling EventHanlerAdapter.DoEvent(), Sender = Object EventRaier, arg = some string
最后，让我们回到现实世界中来。虽然我们用PHP完整地实现了PME模型，但是这到底有什么用呢？毕竟，我们不会用PHP去编写IDE，也不会用它编写应用服务器。回答是，基于PME模型的组件技术可以实现更加方便和更大规模的代码复用。
在基于PHP的应用系统中，虽然插件已经被广泛使用，但是通过组件技术可以实现功能更强大、更加规范和更容易维护的插件。此外，组件技术在实现一些大的Framework(例如，针对Web UI的Framework)时，也是不可或缺的。
Session有效期问题
      Session处理是所有的Web应用都必须面对的问题。PHP中对session有效期的处理，和其他的解决方案有着很大的不同，这是和PHP的工作机制相关的。
      
在传统的client/server应用中，对于session失效的情况，可以交给网络协议自己来处理。无论是client端主动关闭连接，还是因为网
络异常而导致的连接中断，server端都能够得到通知，触发连接中断的事件。只要编程响应这一事件，执行指定的操作即可。但对于web应用来说，情况却
完全不一样。HTTP协议本身是无状态的，也就是说，每当client/server完成一次请求/响应的过程后，连接就会被断开。在断开连接以
后，server并不知道client是否继续“在线”，还会继续发送下一次请求。换句话说，无论client端的用户已经关闭了浏览器窗口，还是用户仅
仅在阅读当前网页并准备在下一秒钟继续浏览，或者用户因为Windows崩溃/停电/硬盘坏掉/网线被拔/地球爆炸而彻底无法再发送下一个请
求，server都一无所知。（在HTTP
1.1中，浏览器可以通过keep-alive参数，来通知server不要在响应请求后主动断开连接，从而实现物理上的长连接。但是，这只是为了提高网
络传输的性能而采取的措施，HTTP在逻辑上仍然是无状态的。）因此，只能通过某种模拟的方式来判断当前session是否有效。如果某个session
在超过一段时间后没有对server端发出请求，server都会判断用户已经“离线”，当前session失效，并触发连接中断的事件。要做到这一
点，server需要运行一个后台线程，定时扫描所有的session信息，判断session是否已经超时。
      
PHP处理session的原理也不例外，但是在具体的实现方式上，却与众不同。这是因为，由于PHP的工作机制，它并没有一个后台线程，来定时地扫描
session信息并判断其是否失效。它的解决之道是，当一个有效请求发生时，PHP会根据某个概率，来决定是否调用一个GC（Garbage
Collector）。GC的工作，就是扫描所有的session信息，用当前时间减去session的最后修改时间（modified
date），同配置参数（configuration
option）session.gc_maxlifetime的值进行比较，如果生存时间已经超过gc_maxlifetime，就把该session删
除。这是很容易理解的，因为如果每次请求都要调用GC代码，那么PHP的效率就会低得令人吃不消了。这个概率取决于配置参数
session.gc_probability/session.gc_divisor的值（可以通过php.ini或者ini_set()函数来修
改）。默认情况下，session.gc_probability =
1，session.gc_divisor=100，也就是说有1%的可能性会启动GC。
这三个参数，session.gc_maxlifetime/session.gc_probability
/session.gc_divisor都可以通过php.ini或者ini_set()函数来修改。但要记得，如果使用ini_set()函数的话，必
须在每一个页面的开始处都调用ini_set()。
      
这又导致了另外一个问题，gc_maxlifetime只能保证session生存的最短时间，并不能够保存在超过这一时间之后
session信息立即会得到删除。因为GC是按概率启动的，可能在某一个长时间内都没有被启动，那么大量的session在超过
gc_maxlifetime以后仍然会有效。当然，发生这种情况的概率很小，但是如果你的应用对session的失效期要求很精确的话，这会导致很严重
的问题。解决这个问题的一个方法是，把session.gc_probability/session.gc_divisor的机率提高，如果提到
100%，就会彻底解决这个问题，但显然会对性能造成严重的影响。另一个方法是放弃PHP的GC，自己在代码中判断当前session的生存时间，如果超
出了 gc_maxlifetime，就清空当前session。
PHP中的session有效期默认是1440秒（24分钟），也就是说，客户端超过24分钟没有刷新，当前session就会失效。要修改这个默认值，正确的解决办法是修改配置参数session.gc_maxlifetime。
      
我曾经在网上搜索过这个问题的解决方式，找到的结果千奇百怪。有的说要设置“session_life_time”，据我知所，PHP中没有这个参数。有
的说要调用session_set_cookie_params，或者设置session.cookie_lifetime，这仅仅用于设置
client端cookie的生存时间，换言之，只当client端cookie的生存时间小于server端的session生存期时，修改这个值才有
效，并且最长不能超过server端的session生存期，原因很简单，当server端的session已经失效时，client端cookie的生
存时间再长也是没有意义的。还有的说要调用
session_cache_expire，这个参数用于通知浏览器和proxy，当前页面的内容应该被缓存多长时间，和session的生存期并没有直
接关系。
听起来，这种解决方案很完美。但是，当你在实际中尝试修改session.gc_maxlifetime的值的时候，你很可能会发现，这个参数基本不起作用，session有效期仍然保持24分钟的默认值。甚至可能出现，在开发环境下工作正常，在服务器上却无效！
        为了彻底解决这个问题，需要对PHP的工作细节进行进一步的分析。
        在默认情况下，PHP
中的session信息会以文本文件的形式，被保存在系统的临时文件目录中。这个路径由配置参数session.save_path指定。在Linux
下，这一路径通常为\tmp，在
Windows下通常为C:\Windows\Temp。当服务器上有多个PHP应用时，它们会把自己的session文件都保存在同一个目录中（因为它
们使用同一个session.save_path参数）。同样地，这些PHP应用也会按一定机率启动GC，扫描所有的session文件。
      
问题在于，GC在工作时，并不会区分不同站点的session。举例言之，站点A的gc_maxlifetime设置为2小时，站点B的
gc_maxlifetime设置为默认的24分钟。当站点B的GC启动时，它会扫描公用的临时文件目录，把所有超过24分钟的session文件全部删
除掉，而不管它们来自于站点A或B。这样，站点A的gc_maxlifetime设置就形同虚设了。
找到问题所在，解决起来就很简单了。在页面的开始处调用session_save_path()函数，它能够修改
session.save_path参数，把保存session的目录指向一个专用的目录，例如\tmp\myapp\。这
样，gc_maxlifetime参数就工作正常了。
      
使用公用的session.save_path还会导致安全性问题，因为这意味着，同一台服务器上的其它PHP程序也可以读取你的站点的
session文件，这可能被用于黑客攻击。另一个问题是效率：在一个繁忙的站点中，可能存在成千上万个session文件，而把许多不同网站的
session文件都放在同一个目录下，无论是对单个文件的读写，还是遍历所有文件进行GC，都无疑会导致性能的降低。因此，如果你的PHP应用和别的
PHP应用运行在同一台服务器上的话，强烈建议你使用自己的session.save_path。
        严格地来说，这算是PHP的一个bug。当PHP在进行GC时，它应该区别来自不同站点的session文件，并应用不同的gc_maxlifetime值。目前，最新的PHP 5.2.X仍然存在这个问题。
        上文说到，在一个繁忙的站点中，可能存在成千上万个session文件，即使区分了不同站点的session.save_path目录，单个站点的session文件数目仍然可能导致效率问题。为了解决这一问题，可行的几种方法有：
    1. 如果PHP运行在Linux系统下，使用ReiserFS文件系统取代默认的ext2/ext3文件系统。ReiserFS对于大量小文件的存取性能，比ext2/ext3有极大的提高。
    2. 将session.save_path指向一个内存路径。这意味着，session文件的读写只在内存中进行，而不执行磁盘操作。
    3. session.save_path接受一个额外的N参数，用于指定目录的级数。例如，“5;/tmp”
将导致创建类似这样的session文件：/tmp/4/b/1/e/3
/sess_4b1e384ad74619bd212e236e52a5a174If。具体的说明，请参见：
http://cn.php.net/manual/en/session.configuration.php#ini.session.save-path
    4. 终极的解决方案，是放弃PHP的session处理机制，自己编码接管所有的session处理操作，通过
session_set_save_handler()函数来实现。通过自己接管session处理，可以将所有的session保存在专门的数据库（往
往使用内存表）中，从而彻底解决session文件带来的问题，并且可以方便地实现session的共享和复制。这也是大型的PHP应用一般会使用的方
式。关于session_set_save_handler()函数的使用，网上和相关图书都有详细的说明，这里不再赘述。值得一提的是，即使在这种方式
下，启动GC的概率仍然取决于session.gc_probability/session.gc_divisor。
Drupal的性能问题
      
Drupal是一个基于PHP的开源CMS系统，也是我认为技术上实现得最好的一个PHP应用。Drupal的架构非常优秀，通过微内核+plugin的
方式，实现了极佳的扩展性，从而使Drupal远远超出一般的CMS这一范畴。从这个意义上来说，把Drupal称为Web
OS似乎更加合适一些。关于Drupal，有太多的话可以说，也许我会在以后的时间里写一篇文章对它进行专门的讨论。但是在本文中，我想讨论的，是
Drupal社区中的每一个人都会面对，但不是每一个人都对其有清晰认识的问题，即Drupal的性能问题。
        因为客户需求，我曾经对Drupal做过比较全面的测试。当时的环境是双服务器（DB server+Web
Server），硬件配置都是单CPU+4G。数据库里面有几千条Node记录。用JMeter对各种情况下（开/关各种cache模块，logged
user/anonymous user）不同页面的读取和写入操作都进行过测试。
        测试的结果可能和很多人印象中不一样。两个主要的结果如下：
    1. Logged user和anonymous user的性能差距非常大。同一个页面，logged
user的RPS(Requests per second)一般不超过20，而启用了cache的anonymous
user的RPS在100多，当使用了file-based cache以后，甚至能超过300。
    2.
数据库压力相对较小。由于Drupal把大量可配置的内容都放在数据库中，因此往往容易产生这样一种印象，即Drupal对数据库要求应该是很高的。但事
实上，无论是cache还是非cache模式，DB server的压力都相当小（CPU在10%以下），而Web
Server的CPU在80%以上。跟踪所有的db query的执行时间后，也证明了这一点（全部db
query的执行时间只占页面生成时间的一小部分）。
        经过反复的测试和思考，我得出了一些结论。很明显，Drupal在大量logged
user并发情况下的瓶颈，在于执行Drupal代码的CPU时间，而不是在于数据库或者其他地方。之所以出现这样的情况，和PHP本身的执行机制和
Drupal的实现方式有关。Drupal在生成一个非cached的页面时，不管这个页面多么简单，都要执行一个完整的bootstrap过程，即使只
启用了最少的模块，这个过程也要调用几十个PHP文件，执行成千上万行PHP代码。而PHP的机制又决定了没有任何PHP代码或者对象能够驻留内存，每次
响应请求都必须执行完整的初始化工作。而anonymous user之所以快，是因为Drupal在执行cached
page的时候，不会执行完整的bootstrap过程，它先检查是否cached page，是的话就读取缓存，然后结束工作。这样当然就快了。
以这个结论为前提，可以解释一些事情：
    1. 为什么Drupal的性能在各种环境下相差并不多。无论是双服务器，单服务器，甚至内存非常小的虚拟机，logged
user的RPS值往往总是在10~20之间。数据库里面有几百条，或者几十万条记录，影响也不大。因为瓶颈并不在于DB或者内存，而是在于执行代码的过
程。
    2. 为什么使用APC/XCache这样的代码优化程序，能够得到极大的性能提升。在我自己的虚拟机环境上，RPS从3~4提升到了12。因为它提升的是PHP代码的执行时间。
        从这个结论出发，列出一些对优化Drupal的logged user性能有明显作用和没有明显作用的措施：
I. 没有明显作用的：
    1. 加内存。在并发数只有10+的时候，即使每个请求占20M内存，也只有200M+内存而已。
    2. DB server和Web server分开，或者增强DB server的配置。一台中等性能的mysql服务器，应付200~300的并发是很轻松的事情，在并发数只有10+的时候，db server实际上是很空闲的。
    3.
基础软件的优化，例如从Windows转移到Linux，从apache转移到Lighttpd，从MySQL迁移到其他数据库，除了从Windows转
移到
Linux会有比较明显的提升以外（因为PHP在Linux上的效率比在Windows上要好），其它的措施可能会快一些，但不会有大幅度的提高，因为瓶
颈不在那里。
II. 有明显作用的：
    1. 使用APC/XCache这样的代码优化程序，速度会有几倍的提升。估计大家都已经这样做过了。
    2. 增加web server的CPU数量。双核的肯定比单核的快，4个CPU肯定比2个CPU快得多。
    3. 使用多web server+单db server的配置，把代码执行的压力分散到不同的web server上。上文说到，单台db server可以轻松应付200+的并发，这意味着理论上可以支持10台以上的web server。
    4. 使用Quercus这样的引擎，把PHP代码编译成Java，再在Java VM中运行，理论上会有很大的提高。原因是，第一，Java的运行效率比PHP高，第二，Java代码是可以cache的，不需要每次都重新加载。这里有个测试结果：
http://www.workhabit.org/resin-backed-php-drives-4x-performance-improvements-drupal
。Drupal在Quercus下有4倍的性能提高，但是这个数字跟Drupal在打开APC/eAccelerator下的提升差不多，所以可能没有太大的实用价值。
另外一种思路是代码本身的优化。
        使用cache API基本上是没有意义的，因为对于logger user，Drupal不会调用cache
API。Drupal.org上有人提出，即使是logged
user，有很多页面也是不用定制化的，这意味着可以cache它们。但是Drupal没有提供这样一种机制。只要是logged
user，Drupal就会执行完整的bootstrap过程，即使只打印出一个hello world，因此实际上你没有办法在logged
user状态下cache单个页面。
        到目前最新版本的Drupal（Drupal 6.4）为止，对于logger
user，Drupal只提供了一种cache功能，就是可以将部分block设置为可cache的。在block占用大量服务器时间的情况
下，block cache能够有效地提高效率。但是，由于block
cache对于bootstrap过程并无影响，因此当瓶颈在于bootstrap本身时，Block cache是无能为力的。
        在Drupal.org的社区，关于logger user的cache问题，一直处于热烈的讨论之中。基本的结论是，由于Drupal的架构就是这样，目前没有很好的解决方案，只能期待Drupal在以后的版本中进行改进了。
      
我研究了一下Drupal的bootstrap过程，发现也许这样是可行的：实现hook_boot函数，这是bootstrap中执行最靠前的一个函
数，它被调用时，bootstrap的大部分过程还没有执行。在hook_boot中，检查当前页面是否需要cache，如果是，直接读
cache生成页面，然后调用exit()强行结束。这在理论上是可行的，但太过hack了一点。
Drupal的情况是这样，那么其他的PHP框架，尤其是半官方的Zend Framework，性能如何呢？通过搜索，我在网上找到了一份PHP framework comparison benchmarks，网址见：
http://www.avnetlabs.com/php/php-framework-comparison-benchmarks
。
根据这份报告的数据，Zend
Framework的性能只有原生PHP的10%，如果没有用APC，连3%都不到。当然，这份报告的数据不一定详尽，Zend
Framework在不同环境下的表现应该也会有出入。但是，Zend Framework的性能大幅度落后于Baseline
PHP，应该是确凿无疑的。
      
为什么PHP主流框架的性能都存在着这样的问题呢？其实这也不难理解。回顾PHP沉思录系列第一篇中对于PHP工作模型的讨论，由于PHP没有驻留内存的
进程，所以每一个request发生时，都必须初始化所有的对象，这导致大量的时间被耗费在进程代码的执行过程中。当PHP程序仅仅是简单的脚本时，这无
关紧要，但是在结构复杂的架构中，由于每次处理request都要重复调用成千上万行代码，这一问题就变得非常突出了。而且，除非PHP以后的版本对这一
机制进行改进，否则这个问题无法得到彻底的解决。
      
那么，这是否意味着，PHP只能适用于小型的网站，而无法在高并发量的大型网站施展拳脚呢？当然不是这样。事实上，在Yahoo和其他许多知名的巨型网站
上，都大量地使用了PHP。原因在于，PHP仅仅被用作一个内容生成器，生成的内容会被转化为静态文本，绝大多数用户浏览的都是被cache的静态文本。
这就和PHP程序的性能毫无关系了。但是，当用户并不是仅仅进行浏览，而是需要频繁地和网站进行互动时，PHP的性能不但无法比拟C和Java，甚至无法
与同为脚本语言的Python和Ruby相比。也就是说，PHP更适合于新闻门户这样的内容发布站点，而不是web 2.0应用的首选。
        在本系列文章告一段落的时候，我们看到的是PHP的局限性。热爱PHP的人们可能会对此觉得沮丧。但是，这并无损于PHP作为一门优秀语言的声誉。尺有所短，寸有所长，对于我们熟悉和喜爱的工具，我们更应该了解它们的局限，这也有利于我们更有效地使用它们。
[zz from] http://www.chinahtml.com/programming/2/2007/php-119069789516247.shtml
[zz from] http://koda.javaeye.com/blog/319605
               
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/87830/showart_2043017.html