Zend Xcache PHP
因本人水平问题, 所有配置均未考虑安全问题
以下所有知识均是为了有限的条件下创造出无限速度
天下武功 惟快不破
关于Zend Engine的知识
自：http://x.discuz.net/405175/viewspace-17014
Zend Engine 最主要的特性就是把 PHP 的边解释边执行的运行方式改为先进行预编译(Compile)，然后再执行(Execute)。这两者的分开给PHP带来了革命性的变化：执行效率大幅提高；由于实行了功能分离，降低了模块间耦合度，可扩展性也大大增强。此时PHP已经能很方便的应付各种各样的BT需求了，而伴随 PHP 4.4.x ―可能是PHP4 系列的最后一个分支―的发布，PHP的大部分开发人员已经将注意力放在了PHP5或者 PHP6上面，以后发布的基本上就是一些 Bug Fix Release。可以说第一代的Zend Engine是已经在站最后一班岗了。
PHP 5 系列的Zend Engine 2就完美无缺了。前面已经提到过，Zend Engine 将代码分成编译和执行两大部分。一般情况下，我们的代码完成以后就很少再去改变了。但执行时PHP却不得不还得一次又一次的重复编译，这根本就是毫无必要的。而且通常情况下，编译的所花费的时间并不比执行少多少，说是五五开并不为过，因此这极大的浪费了机器的CPU。基于Zend Engine 3.0 的 PHP6 将解决这个问题。除此之外，目前的PHP对多字节的字符处理也是PHP的一大致命缺陷。这在人们联系日益国际化的今天几乎是不可忍受的。而无数人在抨击 PHP 或 比较 ASP等同类语言时总是不可避免的要提到这一点。同时受到 IBM 方面的压力，PHP6 也将会把对多字节字符的处理提到首要日程。这在 PHP6 的 Dev 版本中已经得到体现。
一般加速的有MMcache Xcache eAccelerato apc
自：http://www.zhongguowen.com/blog/?p=68
eAccelerator是一个开源的PHP加速、优化、动态内容缓存器。它通过缓存PHP脚本的编译状态码来提升执行性能，因此节省了每次PHP脚本执行都需要预编译的过程。它同时优化脚本的代码执行效率。eAccelerator可以显著减少服务器负载、提升PHP代码执行性能1~10倍。
eAccelerator于2004年12月份以
Turck MMCache 项目的分支的形式诞生。Turck MMCache 项目由Dmitry Stogov创建，并且Dmitry Stogov至今一直为此项目而开发着。
eAccelerator存储PHP脚本在共享内存中、并直接从中执行它们。当发现共享内存中存在所需的PHP缓存代码时，eAccelerator仅花费很短时间的锁开销。因此一个脚本可以被多个执行引擎调用。无法使用共享内存的脚本也可以存储在磁盘上。
APC的缓存分两部分:系统缓存和用户数据缓存.
系统缓存是自动使用的,是指APC把PHP文件源码的编译结果缓存起来,然后在再次调用时先对比时间标记。如果未过期,则使用缓存代码运行。默认缓存3600s(一小时).但是这样仍会浪费大量CPU时间.因此可以在PHP.ini中设置system缓存为永不过期(acp.ttl=0).不过如果这样设置,改运PHP代码后需要restart一下您的web服务器(比如apache…).目前对APC的性能测试一般指的是这一层cache;
用户数据缓存由用户在编写PHP代码时用apc_store和apc_fetch函数操作读取、写入的.如果量不大的话我建议可以使用一下.如果量大,我建议使用memcache会更好.
如果要享受APC带来的缓存大文件上传进度的特性,需要在php.ini中将apc.rfc1867设为1,并且在表单中加一个隐藏域APC_UPLOAD_PROGRESS,这个域的值可以随机生成一个hash,以确何唯一.具体例子请参见前面给出的链接.
PHP一些信息
自：
http://hostingfu.com/article/running-php-on-shared-hosting
First of all, we have our 3 contestants.
- Apache + mod_php — it is by far the fastest way to run PHP scripts,as the PHP interpretor is (1) persistent and (2) in-process. It is alsothe method most widely adopted by the shared hosting industry. If yoursite is on a Cpanel account, then it is most likely to be on mod_php.
As PHP is running in-process along-side with Apache, the PHP scripts are running as Apache’s user (apache or nobody or www-data depending on your Linux distro).
- CGI + SuEXEC— Common Gateway Interface (CGI) is the grand-daddy of dynamic webcontent, and it is CGI that made scripting languages like Perl popularin the late ’90s. A full PHP interpretor is forked for every request ofdynamic content, and process forking is not computationally cheap — atleast in the ’90s. This is the very reason why in-process interpretorslike mod_php and mod_perl became popular.
One advantage, when combining with Apache’s suEXEC, is that CGIs are running as owner of the scripts,i.e. actual shared hosting users. As the cost of forking is gettingrelatively cheaper these days, CGI + suEXEC is becoming popular again.
- FastCGI per user — FastCGIis not a new technology, but because of the popularity of mod_php, itsort of faded in the corner until those new generation frameworks (RoR,Django, etc) brought it back to life again.
In FastCGI, PHPruns externally but persistently, which makes it almost as fast asmod_php. Another advantage is that you can put suEXEC wrappers aroundit so the persistent FastCGI processes can run as the site owner,instead of a shared FastCGI user.
