性能測試實戰總結

1項目背景
        人力資源上線初期，因爲全省40多個電業局臨時決定同時集中使用人力資源系統，這是開發初期沒有想到的事情，因此用戶剛剛使用就反映整個系統速度很慢，項目組和公司領導層高度重視這個事情，但是究竟慢在什麼地方呢？是什麼緣由引發的慢，面對一個這麼龐大而複雜的系統，要想找到真正的緣由是很難辦到的事情，你們都在懷疑和猜想着？是硬件問題？仍是應用服務器慢？仍是數據庫服務器慢呢？圍繞這一系列的疑問，性能測試工做緊張又有條不紊的展開了，而測試組擔負着性能測試的主要重擔，因而安排舒文林負責這個事情。

        2測試流程

        測試組接到任務事後，進行一系列的思考，肯定了將整個系統逐步分解的測試辦法，就是先將系統分紅幾個大塊，應用服務器，數據庫服務器，客戶端程序；而後再將服務器拆成硬件和軟件；而後逐步將應用軟件劃分紅若干邏輯層，測試組舒文林通過和項目組溝經過後，首先找幾個最慢的功能登錄，分頁，人員子集編輯信息，組織機構查詢。經過80人摸擬以上操做同時訪問人力資源系統，在這樣的狀況下，咱們發現壓力主要集中在數據庫服務器上，值得慶興的是，經過觀察應用服務器CPU，內存，磁盤，網絡等資源，一切正常，因此咱們排除了應用服務器引發慢的可能，把注意力集中在數據庫服務器上。

        再觀察數據庫服務器時，咱們發現CPU一直處於100%，磁盤I/O很慢，每秒在283K左右。因而直接想到的是換硬件，開發組決定更換磁盤陣列卡，將數據庫服務器改爲IBM的高檔小型機。這樣性能獲得了必定的提高，但過了不久，用戶又開始有意見了 ，那說明咱們如今的系統性能尚未達到用戶的要求，公司領導層再次組織進行性能測試，說的是必定要挖掘深層次的緣由。

        因而測試組又派出了舒文林負責人力資源項目的性能測試，此時項目組要到了驗收的時候了，這難免無形中給測試組增長了很大的壓力， 這個時候Sybase工程師也來了，怎麼辦呢？仍是老辦法吧，不過此次咱們是先從功能做爲分解點，先找到最慢的功能，一個一個的測試/首先找到的是登錄，咱們把登錄功能按照程序邏輯拆分紅若干小的功能，及顯示登錄頁面，權限驗證，加載主菜單、主畫面等，結果發現登錄功能最慢的是加載主菜單和權限驗證這兩塊，消耗了整個登錄功能大部份的時間，那就給開發人員找到了優化的地方，經過使用高速緩存，創建數據庫索引，優化SQL，優化程序等技術手段事後，登錄功能性能提高了一半；最大支持用戶數也由120增長到了200，接下來按照老辦法，開始分頁功能的測試，因爲Sybase使用分頁必須使用臨時表，先將要分頁的數據放到臨時表，頁面顯示層再從臨時表裏面取出數據填充到客戶端顯示，


        仍是先用80個用戶同時使用該系統分頁，並重復迭帶屢次，這個時候CPU長時間飽和，客戶端時間很滿，達到70秒，先記錄做爲基準測試。
        再看數據庫的各類指標，咱們發現數據庫有嚴重的阻塞，終於有了根本性的發現。Sybase工程師想到經過綁定多個臨時表，並經過ASE的同步機制來保持同步，這樣阻塞問題緩解了，響應時間也由70秒降到了30秒。可是當用戶數增長到120的時候，數據庫CPU又是100%，系統又慢了下來，並且系統其它功能也都慢了下來，咱們分析了一下，以爲經過增長多個臨時表和多個臨時庫，這樣會不會帶來額外的CPU開銷呢？確定會的，但這個開銷究竟有好大呢？這是一個尚未肯定的問題？若是CPU開銷小了，系統性能確定會好起來，由於目前就CPU是個瓶勁。

        這個時候，Sybase工程師說他們已經作到最優化了，而開發人員也以爲他們該作的都作了，那爲何如今系統還慢呢？憑個人經驗，我以爲這筆開銷很大，但我又沒法證實這一點，Sybase工程師認可這須要額外的CPU和內存開銷，但究竟多大，也是一個疑問。爲了弄清楚這個問題，咱們選在在同一臺計算機上將分頁的功能作一個比較，咱們拋開應用服務器，經過直接測試分頁腳本，來比較各自的性能。採起在該服務器上全新安裝操做系統和必要的軟件，作成Ghost恢復文件。

        而後分別測試Sybase和Oracle，首先安裝Sybase產品，進行測試後，而後用Ghost恢復系統到初始化環境，安裝Oracle，採用和Sybase相同的測試案例進行測試， 並將oracle和Sybase調整到最優化，最後將兩個測試結果彙總，測試過程忽略不計，結論是Sybase進行翻頁CPU是100，而oracle是25%，Oracle分頁因爲有ROWNUM字段，因此不須要使用臨時表，響應時間都在40秒左右，由於咱們找的計算機很普通，因此時間長了點，因此咱們得出Sybase使用臨時表分頁消耗CPU很大的結論，人力資源系統性能的測試和研究在之後的歷程中，任務將會更加艱鉅，咱們徹底有信心克服困難，打敗困難，由於咱們已經積累了不少經驗。