第一章  針對系統調用過多的優化
我這次的優化針對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小時）。