以前做的一個有關Page Cache方面的
測試，今天提出來說說我的測試方法，希望對讀者有所幫助。
問題回顧
由于網(wǎng)站被頻繁請求的頁面為動態(tài)生成WEB頁，導致消耗大量系統(tǒng)資源，為了提高用戶對此類網(wǎng)頁訪問的響應時間，采用對其該部分頁面使用Cache技術。
對于這種類型的測試其實很簡單，只要求測試人員做到以下兩點就完全可以應付：
1、對Cache在業(yè)務中的實現(xiàn)規(guī)則有充分了解（具體說來就是，有哪些頁面使用了Cache，Cache的有效時間長度為多少，被測服務器端物理內存為多少，分配了多少空間給了Cache）。
2、理解在測試過程中需要重點關注的相關性能計數(shù)器（例如內存）。
測試第一步，驗證
驗證Cache是否存在，是否滿足實現(xiàn)規(guī)則。例如訪問一個已經(jīng)加有Cache的動態(tài)頁面，第一次請求的頁面響應時間為10秒，第二次為3秒，90 Percent 的響應時間不大于4秒，那么我們暫時可以認為Cache生效。在隨后的測試過程中，使用ramp -up 方法對Cache進行測試，看到response time結果大致為，當?shù)谝粋€線程訪問該頁面時，RPT在一個很高的起點上，因為這時Web 服務器必須訪問數(shù)據(jù)庫， 并生成頁面，再將其存儲在緩存中，這個過程消耗了大部分RPT，運行到第二線程時RPT成曲線下降到一個很低的點上，這是因為第二線程直接從內存中的 Cache里讀到了所需的頁，這個點和隨后增加的線程幾乎在同一水平線上，平穩(wěn)延續(xù)，當場景運行到20分鐘左右，正好是到了Cache生命周期結束的時間 點上，重復以上描述RPT曲線軌跡。在這里RPT不是隨著用戶的上升而上升，給人的感覺象是使用了COOKIE。
測試第二步，并發(fā)
通過設置并發(fā)點對同一動態(tài)頁面的訪問，測試Cache是否有等待時間過長的現(xiàn)象。因為第一到達目的地的線程會先到內存中存儲它訪問完數(shù)據(jù)庫并生成完頁面 的緩存，這個時候其他線程只有乖乖等待第一線程做完寫操作后方可進行讀操作，大家知道一個線程在一次操作過程中只允許有寫或者是讀的權限，兩種權限不允許 在一個線程內同時進行，如果程序中的線程同步鎖處理的不夠好，那么可能會導致意外情況發(fā)生。例如在多用戶同時訪問該頁面時，可能會出現(xiàn)所有線程請求失敗， 遇到這種情況，測試人員可以先多嘗試用串行或者不加并發(fā)點進行測試并得出結論。根據(jù)經(jīng)驗遇到這種問題大多數(shù)為線程同步機制出現(xiàn)問題所導致。在測試過程中要 更多關注WEB SERVER 的內存計數(shù)器其中包括（頁交換比率\ pages reads\ private byte\ working set ）如果緩存命中率底，那么內存頁交換和pages reads會很高，如果大用戶量訪問，內存不能及時釋放空間，則 working set和private byte會很高，如果懷疑有memory leak現(xiàn)象，可以把其他相關業(yè)務同時加上，把執(zhí)行場景的時間拉長一些，看對其他業(yè)務的影響程度。在這里Cache的命中率是Cache的關鍵問題，如對 以上計數(shù)器不是很理解還請查一下相關幫助文件，在這里就不做過多解釋了。
使用Cache的優(yōu)點
節(jié)省生成頁面時所消耗的CPU和內存資源。對于大用戶量的訪問使RPT一樣變的很短。
對數(shù)據(jù)庫的壓力減少是顯而易見.我個人覺得這個是最重要優(yōu)勢。
對于最終用戶和服務器之間，用戶的請求時間變短了，那么就縮小了服務器的資源浪費。