第一章  针对系统调用过多的优化
我这次的优化针对syscall调用过多的问题，所以使用strace跟踪apache进行分析。

1.  apache2ctl -X &
使用-X(debug)参数启动httpd进程，这个时候只启动1个httpd进程
2. ps -ef | grep httpd
找到需要strace的pid
3. strace -p $PID -o /tmp/strace.log
发送一个http请求到httpd，就能看到strace信息了。
 
一、include_path问题

一般可以看到很多这类信息：
stat64("/error/dir/test.php", 0xbfab4b9c) = -1 ENOENT (No such file or directory)
解决方法：
1. 在应用php里面设置include_path，去掉'.'等相对路径，将其中包含使用文件比较多的目录放到前面。保证遍历include_path的时候能够很快找到。
2. 使用绝对路径进行include，require，include_once，require_once
3. 使用php的自动加载机制
 
二、apache的rewrite配置

复制代码 代码如下:
    RewriteEngine On
    RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
    RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
    RewriteRule .* %{DOCUMENT_ROOT}%/index.php
   #RewriteRule .* /index.php

这里最后一个注释掉的rewrite配置不好，因为它每次请求都会多一次syscall
stat64("/index.php", 0xbfab4b9c) = -1 ENOENT (No such file or directory)
 
三、apache日志问题
我们在测试一个问题的时候，发现如果自定义日志里面记录了访问时间等信息，会多出很多
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=165, ...}) = 0
如果记录的日志比较多，性能下降非常严重，对于简单应用，记录复杂日志，性能会下降30倍。
解决方法：
在多个apache前端架http层的proxy，如haproxy，nginx。在这些地方记录日志。接入层负载一般不高，所以proxy可以做一些记录日志的工作。在这种配置下，可以关闭apache的日志。
 
四、realpath()问题
大家可以看一下这篇文章：http://bugs.php.net/bug.php?id=43864
lstat64调用多了之后，主机CPU和IO都会比较高。
究其原因，因为php5.2.x对realpath()的实现不够好，导致会针对目录层次，逐级调用lstat64()。
为了解决这个问题，它使用了realpath_cache，针对某个文件，存储其realpath。这里只存储了叶子节点的realpath，而对 路径上的内容没有存储，所以在做"/a/b/c/d/e/f/g/a.php"realpath检查的时候逐级调用lstat64，而在做"/a/b/c /d/e/f/g/b.php"检查的时候，还要对""/a/b/c/d/e/f/g/"做逐级检查。所以有些优化建议就是"减少目录层次，甚至放到"/"根目录下"。当然我不推荐这么干。从5.3.0开始，php对realpath()做了高效的实现，路realpath的中间路径也做了缓存，以上面的情况为例，检查"/a/b/c/d/e/f/g/b.php"的时候就只会做"b.php"的检查了。所以，升级到php5.3.0以上版本能够很好地解决这个问题。
解决方法：
1. 尽量少用include_once和require_once
因为这两个函数会做realpath检查，防止有符号链接的情况导致重复加载。不用它们就能减少realpath的调用。
2. 合理设定php.ini中的realpath_cache_size和realpath_cache_ttl参数
既然使用了realpath_cache，那肯定有大小限制。对于使用了很多文件，比如用了Zend Framework的项目，可能默认realpath_cache_size=16k就太小了，需要增大这个设置，推荐设置为256K以上。另外默认realpath_cache_ttl=120，2分钟就过时了，怎么也要设定为3600（1小时）。