一個產品的編碼完成，并不能代表產品能夠給用戶體驗，其中還必須包含測試、壓測分析等，而往往我們的產品上線前卻忽略掉壓測分析。既然壓測分析很重要那么我們應該如何進行呢？

本文章主要通過實踐經驗來學習了解壓測過程，并且提出一些在PHP端可以進行優化的功能點，從而幫助后續開發過程中應用最優方式去編碼。

有道是磨刀不誤砍柴工，要有好的工具才能做事更有效率，要學會工具的應用才能更進一步的優化系統項目。

關于PHP的工具性能檢測工具的話，可以應用xhprof工具或者CI的原生時間打印工具。Xhprof工具的使用方法大家可以參考：http://blog.snsgou.com/post-278.html。

CI原生工具打印時間則了解CI中Benchmark類庫中關于mark方法的應用，其主要是針對mark中包含*_start和*_end的所有標記時間添加到CI的debug頁面信息中。因此如果我希望查看某個類庫的加載時間，我只需要做例如下面的處理方式：

$BM =& load_class('Benchmark', 'core');$BM->mark('base_classes_start');// load base classes$BM->mark('base_classes_end);

如果這樣一個個添加會讓你覺得很蛋疼，因為類庫太多了，那么這里就可以應用小技巧，你只需要在load model和load library處添加該處理功能，那如果使用的是原生的require時，則會相對較為麻煩。

在調整如上代碼時，切記要備份一份完整的代碼。將如上的工具都應用到項目代碼中后，我們接下來就是來分析需要優化的接口。

在壓測前首先你需要解決那些很明顯的問題，比如說一個請求會多次加載類庫、一個請求會多次請求memcached中相同數據、一個請求會多次請求redis中相同的數據、一個請求會多次的new一個類庫等等。而這些問題都可以在壓測前分析解決。以下是一個自我檢測表格，如果大家以后有需要可以進行相應的檢查并優化。

優化問題

分析

優化方向

備注

多次加載類庫

在創建類似redis、memcached以及mongodb的類庫時，都會在構造函數中創建連接，而如果處理不當時則會加載多次創建多個句柄，導致服務端句柄連接非常多，加大每個連接處理的時間。

如果有長連接方式則盡量使用長連接，如果沒有則在每次連接時，應用靜態變量保存，下次需要重新創建連接時則進行判斷，避免一個請求產生多個句柄。

一般經常性使用的類庫都有做這種處理，但也不排除未做處理的，因此在壓測前可以好好的查看一下。

單個數據多次請求緩存

在正常情況下，大家都會覺得既然是讀取緩存那么效率上應該很高，所以一般情況下需要數據時都直接讀取緩存內容。這樣會導致一個情況是單個數據的緩存可能被請求了多次。

首先需要知道哪些數據被請求了多次，因此可以在緩存的get方法中添加日志，記錄每一次讀取緩存的key值，最后再分析查看哪些數據被讀取了多次。從而來進一步優化，在緩存讀取完成后，使用一個靜態數組保存讀取完成的數據，如果讀取過則直接從本地內存中獲取，而無需遠程緩存數據。

如果緩存在靜態變量中相當于讀取本地內存，而如果應用其他緩存工具，則會在創建連接以及算法上有細微的差距。而如果在高并發的情況下，這種對比就會被無限的放大。

關閉debug日志

一般PHP系統都會存在debug日志，在壓測并非時可能會存在影響，因此最好是關閉debug模擬現網只有info和error日志內容。

關閉debug日志，保留info和error，與現網保持一致。

這部分在低并發時也時也很難看出問題，但在高并發時可以明顯看出這會影響到系統性能，因此在壓測前以及現網必須要進行關閉。

對以上三個方向進行了優化后，我們接下來就開始準備對系統進行壓測分析。

壓測前需要注意以下幾點：

1、壓測前必須要保證去除登錄邏輯，并能夠進入正常的數據請求；

2、壓測將接口分析以便同一類接口，可以避免修改邏輯一起壓測；

3、壓測數據表格設計，盡量能夠設計分析出系統的極限處理能力，例如下面表格；

壓測并發

壓測請求量

壓測服務器

吞吐量

Xhprof標準

20

10000

236

510

http://xxx

50

10000

236

550

http://xxx

4、應用xhprof工具打點分析，為了xhprof不影響現網的運行，可以使用概率打點方法。

如果前期準備完善的話，接下來的壓測就較為簡單了，只需要跑一下流程，然后查看一下xhprof打印的數據，并且記錄下xhprof頁面url以及壓測結果的吞吐量。這部分需要注意的一點是必須要等被壓測服務器的負載降低時才能進行下一次壓測，避免壓測未達到最佳性能。

1、壓測數據分析

如果前期壓測數據都已經完成后，再將壓測表格數據做成一個折線圖（繪制折線圖的方法，可以使用execl）。通過折線圖分析出系統服務器的最佳并發以及最佳并發下的最大吞吐量，例如下面的折線圖。

分析完成以后，就可以看到服務器在大概100并非時是最大的性能，因此我們接下來就可以分析在100并發以后系統代碼運行的異常問題。

2、xhprof性能分析

從上面的數據分析后，對于100并發前的性能就無需進行查看，而對100并非后的xhprof結果進行分析，細致的查看每個函數的處理時間以及請求次數。再記錄完這些數據后，在通過源碼對比，查看是否有部分接口可以再進行優化，或者說再進一步降低請求次數從而達到優化的目的。

在進行壓測后發現，mongodb的連接和讀取都會對系統產生一個非常大的影響，因此我記錄下了其優化方案（加大緩存時間，并整改代碼，在擁有緩存數據時則不加載mongodb類庫，如果沒有緩存則加載類庫，即修改基類，在構造函數中不直接加載mongodb類庫，而是單獨的添加一個方法來加載mongodb類庫）。

完成壓測后，對代碼進行部分的整個優化（整改前請注意備份），優化完成后再跑一遍代碼邏輯，避免整改后服務異常，從而未達到壓測邏輯的目的。

代碼完成以后再進行下一輪的壓測對比，而這時的對比就可以看出優化后的明顯變化，這也會讓我們的信息進一步提升，讓我們對壓測過程更加充滿一種滿足的感覺。

在PHP壓測優化過程中整體學到了很多知識，在后續的開發過程中則會更加有經驗，我也希望通過這個簡短的總結能夠讓大家了解更多學習更多。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。