PHP优化

首先我们了解一下我们的php程序是怎样执行的，首先他被编译为中间代码，然后中间代码被送入执行引擎执行，然后销毁。每个请求的中间代码在执行完之后被销毁，这样的好处在于他完全隔离了不同的请求，使内存使用率降低。但是这样的缺点也显而易见，因为他需要再重复请求一个界面的时候对一个代码连续编译两次，编译的中间代码没有一点复用性。

我们拿ZPS来说事，看他能提供什么优化功能：
一， 自动优化，也就是我们的zend optimizer提供的功能，他可以对中间代码进行优化，这些优化是语言方面的，将效率低的转化为效率高的，但他的优化目标只限定在中间代码，因此不会影响你编写的源代码。这个能提高20%左右的性能。
二， 代码编译缓存，就是使中间代码更有复用性。因为他会把中间代码进行缓存，下次使用的时候就不需要编译了，这个有50%到300%的性能提升。
三， 动态内容缓存，也就是把php代码执行完之后生成的内容进行缓存，这个适用于幂等的请求，而且请求不会对服务器端的数据造成修改，而只是get数据内容。这个提升效果最大，但对于个性化的界面不太适合，您可以选择使用部分缓存的方式，但明显提高了复杂度。
四，内容压缩：他主要是提高HTTP的传输效率，使传输量减少90%左右，但他也有牺牲，就是增加了两端（c/s）的计算量。但ZPS使用对压缩文件也进行缓存的方式来减少压缩所带来的性能影响。


另外就是细节方面的性能考虑：
1.对于require和include:
不是说使用上apc就一劳永逸了。
Include_once(),require_once()比include，require要慢，因此可以考虑将require_once()换成require().
另外包含一个文件会增加许多内存使用，因此对于大的包含文件你应该考虑如何切割成多个小文件，因为opcode缓存只能优化加载时间，而不会减少内存使用大小。
2.少用define ，在类中使用const变量来代替，因为据说后者可以被opcode缓存，而前者不能。
3.使用C语言。很多人认为“你应该到达不到这种优化需求吧”，但是确实我在写一个推荐系统的时候遇到这个需求，如何在php中使用c来优化性能这个问题留给以后吧，等我研究明白了再贴。
4.使用面向过程代替面向对象。具体原因不知道为什么。另外http://www.iteye.com/topic/143440这篇文章中提到的”php的最佳实践就是数组编程”也很有新意，大部分也是基于性能的考虑。



另外一些小的优化技巧，我这里就不说了，看下面链接。

40条优化PHP代码的小提示：
http://www.huomo.cn/archives/40_tips_for_optimizing_your_php_code.html

php效率优化
http://cnhawkwing.iteye.com/blog/69100



PHP却完全不是这样。作为一种纯解释型语言，PHP脚本在每次被解释时进行初始化，在解释完毕后终止运行。这种运行是互相独立的，每一次请求都会创建一个单独的进程或线程，来解释相应的页面文件。页面创建的变量和其他对象，都只在当前的页面内部可见，无法跨越页面访问。在终止运行后，页面中申请的、没有被代码显式释放的外部资源，包括内存、数据库连接、文件句柄、Socket连接等，都会被强行释放。
　　也就是说，PHP无法在语言级别直接访问跨越页面的变量，也无法创建驻留内存的对象。

......

PHP这种独特的工作模型的优势在于，基本上解决了令人头疼的资源泄漏问题。Web应用的特点是大量的、短时间的并发处理，对各种资源的申请和释放工作非常频繁，很容易导致泄漏。同时，大量的动态html脚本的存在，使得追踪和调试的工作都非常困难。PHP的运行机制，以一种非常简单的方式避免了这个问题，同时也避免了将程序员带入到繁琐的缓冲池和同步等问题中去。在实践中，基于PHP的应用往往比基于Java或.NET的应用更加稳定，不会出现由于某个页面的BUG而导致整个站点崩溃的问题。(相比之下，Java或.NET应用可能因为缓冲池崩溃或其他的非法操作，而导致整个站点崩溃。)后果是，即使 PHP程序员水平不高，也无法写出使整个应用崩溃的代码。PHP脚本可以一次调用极多的资源，从而导致页面执行极为缓慢，但是执行完毕后所有的资源都会被释放，应用仍然不会崩溃。甚至即使执行了一个死循环，也会在30秒（默认时间）后因为超时而中止。从理论上来说，基于PHP的应用是不太可能崩溃的，因为它的运行机制决定它不存在常规的崩溃这个问题。在实践中，很多开发者也认为PHP是最稳定的Web应用。
　　但是，这种机制的缺点也非常明显。最直接的后果是，PHP在语言级别无法实现跨页面的缓冲机制。


http://www.bloggern.com/1557.html

http://www.bloggern.com/3577.html