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

本文章主要通過實(shí)踐經(jīng)驗(yàn)來學(xué)習(xí)了解壓測過程，并且提出一些在PHP端可以進(jìn)行優(yōu)化的功能點(diǎn)，從而幫助后續(xù)開發(fā)過程中應(yīng)用最優(yōu)方式去編碼。

有道是磨刀不誤砍柴工，要有好的工具才能做事更有效率，要學(xué)會(huì)工具的應(yīng)用才能更進(jìn)一步的優(yōu)化系統(tǒng)項(xiàng)目。

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

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

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

如果這樣一個(gè)個(gè)添加會(huì)讓你覺得很蛋疼，因?yàn)轭悗焯嗔耍敲催@里就可以應(yīng)用小技巧，你只需要在load model和load library處添加該處理功能，那如果使用的是原生的require時(shí)，則會(huì)相對較為麻煩。

在調(diào)整如上代碼時(shí)，切記要備份一份完整的代碼。將如上的工具都應(yīng)用到項(xiàng)目代碼中后，我們接下來就是來分析需要優(yōu)化的接口。

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

優(yōu)化問題

分析

優(yōu)化方向

備注

多次加載類庫

在創(chuàng)建類似redis、memcached以及mongodb的類庫時(shí)，都會(huì)在構(gòu)造函數(shù)中創(chuàng)建連接，而如果處理不當(dāng)時(shí)則會(huì)加載多次創(chuàng)建多個(gè)句柄，導(dǎo)致服務(wù)端句柄連接非常多，加大每個(gè)連接處理的時(shí)間。

如果有長連接方式則盡量使用長連接，如果沒有則在每次連接時(shí)，應(yīng)用靜態(tài)變量保存，下次需要重新創(chuàng)建連接時(shí)則進(jìn)行判斷，避免一個(gè)請求產(chǎn)生多個(gè)句柄。

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

單個(gè)數(shù)據(jù)多次請求緩存

在正常情況下，大家都會(huì)覺得既然是讀取緩存那么效率上應(yīng)該很高，所以一般情況下需要數(shù)據(jù)時(shí)都直接讀取緩存內(nèi)容。這樣會(huì)導(dǎo)致一個(gè)情況是單個(gè)數(shù)據(jù)的緩存可能被請求了多次。

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

如果緩存在靜態(tài)變量中相當(dāng)于讀取本地內(nèi)存，而如果應(yīng)用其他緩存工具，則會(huì)在創(chuàng)建連接以及算法上有細(xì)微的差距。而如果在高并發(fā)的情況下，這種對比就會(huì)被無限的放大。

關(guān)閉debug日志

一般PHP系統(tǒng)都會(huì)存在debug日志，在壓測并非時(shí)可能會(huì)存在影響，因此最好是關(guān)閉debug模擬現(xiàn)網(wǎng)只有info和error日志內(nèi)容。

關(guān)閉debug日志，保留info和error，與現(xiàn)網(wǎng)保持一致。

這部分在低并發(fā)時(shí)也時(shí)也很難看出問題，但在高并發(fā)時(shí)可以明顯看出這會(huì)影響到系統(tǒng)性能，因此在壓測前以及現(xiàn)網(wǎng)必須要進(jìn)行關(guān)閉。

對以上三個(gè)方向進(jìn)行了優(yōu)化后，我們接下來就開始準(zhǔn)備對系統(tǒng)進(jìn)行壓測分析。

壓測前需要注意以下幾點(diǎn)：

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

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

3、壓測數(shù)據(jù)表格設(shè)計(jì)，盡量能夠設(shè)計(jì)分析出系統(tǒng)的極限處理能力，例如下面表格；

壓測并發(fā)

壓測請求量

壓測服務(wù)器

吞吐量

Xhprof標(biāo)準(zhǔn)

20

10000

236

510

http://xxx

50

10000

236

550

http://xxx

4、應(yīng)用xhprof工具打點(diǎn)分析，為了xhprof不影響現(xiàn)網(wǎng)的運(yùn)行，可以使用概率打點(diǎn)方法。

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

1、壓測數(shù)據(jù)分析

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

分析完成以后，就可以看到服務(wù)器在大概100并非時(shí)是最大的性能，因此我們接下來就可以分析在100并發(fā)以后系統(tǒng)代碼運(yùn)行的異常問題。

2、xhprof性能分析

從上面的數(shù)據(jù)分析后，對于100并發(fā)前的性能就無需進(jìn)行查看，而對100并非后的xhprof結(jié)果進(jìn)行分析，細(xì)致的查看每個(gè)函數(shù)的處理時(shí)間以及請求次數(shù)。再記錄完這些數(shù)據(jù)后，在通過源碼對比，查看是否有部分接口可以再進(jìn)行優(yōu)化，或者說再進(jìn)一步降低請求次數(shù)從而達(dá)到優(yōu)化的目的。

在進(jìn)行壓測后發(fā)現(xiàn)，mongodb的連接和讀取都會(huì)對系統(tǒng)產(chǎn)生一個(gè)非常大的影響，因此我記錄下了其優(yōu)化方案（加大緩存時(shí)間，并整改代碼，在擁有緩存數(shù)據(jù)時(shí)則不加載mongodb類庫，如果沒有緩存則加載類庫，即修改基類，在構(gòu)造函數(shù)中不直接加載mongodb類庫，而是單獨(dú)的添加一個(gè)方法來加載mongodb類庫）。

完成壓測后，對代碼進(jìn)行部分的整個(gè)優(yōu)化（整改前請注意備份），優(yōu)化完成后再跑一遍代碼邏輯，避免整改后服務(wù)異常，從而未達(dá)到壓測邏輯的目的。

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

在PHP壓測優(yōu)化過程中整體學(xué)到了很多知識(shí)，在后續(xù)的開發(fā)過程中則會(huì)更加有經(jīng)驗(yàn)，我也希望通過這個(gè)簡短的總結(jié)能夠讓大家了解更多學(xué)習(xí)更多。

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。