問題
我正在嘗試診斷我正在開發的 Drupal 網站上的效能問題。早上，當網站超過 8 小時沒有看到任何流量（甚至沒有運行 cron）時，主頁加載時間約為 3.5 秒。重新載入頁面預計需要 250 毫秒。
這是一個開發 Web 伺服器，安裝了相當舊的 PHP 版本 (5.3.3)。所有檔案都透過 NFS 靜態安裝（我認為這是根本原因，更多內容請見下文）。
為了幫助診斷，我安裝了XH教授在此開發伺服器上，並啟用了一個 Drupal 模組，該模組可分析頁面載入並在可很好排序的表格中顯示分析資料。對於不熟悉 XHProf 的人來說，它提供了每個呼叫的函數的數據，以及花費的總時間、記憶體使用情況和該函數的呼叫等資訊。
我的發現
在最初的“緩慢”打擊中，PHP 函數file_exists採取了1400毫秒來自 82 個調用，約佔總執行時間的 43%。在隨後的頁面加載中，相同的函數file_exists再次被調用 82 次，但這次顯著減少到僅3毫秒只佔總執行時間的1%。
我還查看了 PHP 加載到內存中所需時間最長的文件（我認為這就是load::函數名稱上的前綴的含義）。這個 PHP 模板檔案花費了巨大的時間42毫秒第一次加載，並且僅3毫秒在隨後的重新加載中！
我懷疑什麼
我很清楚某處正在進行某種快取 - 我只是還不知道在哪裡。 PHP 文檔為文件已存在提到這個函數的輸出被緩存。然後我發現我可以控制該快取的大小它可能應該從預設的 16k 增加到更適合 Drupal（載入大量相關檔案）的值。
然而，雖然我認為這會減少 中花費的時間file_exists，但我不確定這會影響 PHP 實際花費的時間載入中文件（load::我之前提到的）並增加該值似乎只是隱藏了文件系統的潛在性能問題。
問題
- 是否有任何 XHProf 或 PHP 老手可以確認 PHP 的增加是否對 XHProf
realpath_cache報告的時間有任何影響？load:: - 我應該注意 Linux 中哪些可能產生影響的底層快取機制？
- 與上面相同，但是對於 NFS？