至於線上系統的效能方面議題，在系統研發階段已有雛型、亦或系統即將實際上線前，若開發人員想瞭解 Web Server、AP Server，或資料庫的同時連線負載能力時，一般都是以壓力測試軟體來模擬同時間大量的使用者存取情況。在微軟的世界中，因為工具較為充足，例如版工在開放下載的畢業專題書面中，所提到的 ACT(Application Center Test) 這套工具就相當好用。而在「SQL Server 效能調校聖經 (胡百敬著)」這本書中則提到：
「若是在 Unix 環境中，例如若是要測試一套 ERP 系統，可能就沒有適當的工具能製造壓力，因此若要測試 200 人上線的情形時，就需要真的號召 200 人分批測試，每 10 分鐘增加 20 人。也就是第一個 10 分鐘，先由 20 個人上機執行測試工作。下一個 10 分鐘，原先的 20 個人仍然繼續測試，但同時加入第二批的 20 人。直到 100 分鐘時，就共有 200 人同時在線上存取，並在此過程中觀察系統變化的情形。
也由於沒有監控工具，所以工程師必須自己寫批次命令，每 5 分鐘手動執行一次，以記錄資料庫的情況，另一位工程師看著網路流量與 CPU 和記憶體的使用率，每 5 分鐘手抄各種數值一次。其他工程師則散佈在公司的各個角落，監控測試的同仁是否有任何問題，以回報在機房管控的同事。
測試過程可能熱鬧非凡、沸沸揚揚，一會兒電話打不通，一會兒測試人員不知道跑到哪去了。而整體測試過程中到底在哪個環節有多少人上線，對系統有多大壓力，都很難確定。畢竟公司企業不是軍隊，不可能要求所有人從第 1 分鐘就競競業業地執行測試過程。同仁們能夠照著要求，有一動沒一動地持續在做事就已經不錯了，畢竟人是需要上廁所，聊天和休息的。也由於壓力與效能測試在 Unix 系統較難評估，因此大幅增加備載運算的能力往往是常態，避免買又貴又大的機器進公司後，居然效能不足，最後只能當備援機器來使用。
因此要是開發人員需要較為精準地測試，並廣泛地蒐集資料，隨時能依不同狀況調整施加壓力、持續增大壓力，直到系統癱瘓，在過程中分析各種可能與其因應之道，此時就需要額外的壓力測試工具。」
剛剛版工提過在 Windows 平台上使用 ACT 這套工具是最理想的，但 ACT 有一項缺點，就是在測試時只能走 80 埠連至伺服器上來作施壓。版工在做專題時，曾經嘗試用 ACT 對伺服端上的 PHP 和 JSP 檔案作連結施壓，卻都曾出現錯誤訊息。 PHP 是放在 IIS Server 上讓它走 80 埠，原本用戶端在用瀏覽器連結時運作完全正常，但用 ACT 從用戶端做連結測試時，卻會出現莫名的錯誤導致無法測得相關數據。但根據微軟 MSDN 的說法，應該是只要遵守 HTTP 協定，用戶端用 ACT 走 80 埠都可以連結測試才對；而 JSP 放在 Tomcat 上，走 8080 埠時，以 ACT 來作連結測試，更是直接出現通訊埠錯誤的訊息。網友們若有興趣可自行測試，看是否能以 Visual Studio.NET 企業版中內附的 ACT，以 80 埠去連結並測試異質平台的線上系統和資料庫 (或做 DoS 阻斷攻擊？)。
但若網友們需要測試 PHP、JSP 等伺服端網頁的效能，或需要在 Linux 及其它平台上測試，而又沒有充裕的經費購買專業級的測試軟體，還可以考慮另一套開放源碼，且為純 Java 所撰寫的軟體，即 jakarta.apache.org 網站上的 JMeter。它同樣也是一套用來做效能測試的軟體，但可同時支援 Windows、Linux、Solaris 平台，並且能夠測試 Servlets、Java Objects、Database 和 Queries、FTP Server、Web Server 和 EJBs …等等，以及一些 Web Container 的運作效能，也能自行設定施壓的「同時連線數」。只是該套軟體的技術支援文件較少，但國內一些討論區仍有相關討論連結。除了 JMeter 之外，另外還有像是 WebLOAD …等等一些有提供免費下載，但需要先註冊才能使用的測試軟體，有需求的網友可靠自己努力搜尋及試用。
最後再把主題拉回 ACT 上。在 Windows 平台上運作的 Web Applications，以 ASP.NET + ADO.NET 來開發，其效能為最佳已無庸置疑，而且在未來的 ASP.NET 2.0 技術上的效能增益會更為明顯。這類的「微軟派」線上應用程式，在以 ACT 做壓力測試或效能測試時，還有一點必須要非常注意，就是其可設定的「同時連線數」並不等同於「同時上線人數」。如下圖 1 所示，其為 ACT 的設定畫面，若不明其原理而設定錯誤，可能導致整個效能測試計劃的結果數據，與系統真實上線後的負載情況產生嚴重落差。遺憾的是微軟在 ACT 的中文說明文件，以及 MSDN 中文網站內的文件都未曾說明這一點，只概略提到：「一個 "同時連線數" 代表一條執行緒 (Thread)」。 版工當初在做專題時，翻了不少 MSDN 原文網站上的技術文件才找到答案，後來發現在「SQL Sever 效能調校聖經」這本書中也有提到這項觀念，也就是我們在圖 1 中設定不同的「瀏覽器同時連線數」時，是以不同的執行緒數目施加壓力，因為執行緒其為每一秒都不斷在施壓，因此無法代表一般真人使用者上線時給予伺服器的負載情況。
一般來說不能以一條執行緒代表一個使用者在存取，也就是說若我們以 20 條執行緒去加壓，並不等同 20 個人同時上線存取。因為使用者對網頁的存取不可能像機器般無間段地動作，使用者需要時間來閱讀資料、敲打鍵盤、表單輸入、移動滑鼠並外加聊天、摸魚、喝茶、抽煙、上廁所等其它閒置動作。可能在加壓完畢後，改以「完成的工作量」來推估，會比較能類比同時上線人數的壓力。譬如說以 20 條執行緒加壓 5 分鐘填了 1000 張表單，因此 1 分鐘整個系統完成了 200 張表單，此完成的表單數目即為工作量。而這類線上填表單的系統一般來說，一個人假設可能需要 1 分鐘才能填完一張表單，因此若設定模擬 20 條執行緒，亦即在 ACT 中所設定的「瀏覽器同時連線數」為 20，其所代表的壓力就約等於 200 個人同時上線。而在各位網友的單位或公司中，若經過你們測試得到伺服器硬體配備可承受的「瀏覽器同時連線數」最適值為 30，其所代表的意義就不僅只是 ACT 能模擬 30 個使用者同時上線對伺服器施壓，而可能是 300 個，甚至更多的使用者數量。而每台伺服器主機所能承受的「同時連線數」數量，除了和貴公司的網路頻寬有關，最主要還是看該主機硬體配備的等級而定。
在測試的過程中，也可搭配其它的記錄與偵測工具，例如：Windows 中內建的效能監視器、SQL Server 中的 SQL Profiler…等等，以同時觀察各個伺服器與應用程式的執行狀態，是否能讓伺服端的 CPU 使用率達到 80% 以上的負載率，但又不至於過於滿檔持續一直在 100% loading，以建置出最適當的測試平台，因為在測試的過程中，伺服端上過高或過低的 CPU 使用率都會導致測試結果的不準確。此外，也應該觀察執行測試的用戶端主機，是否本身就已經因為多執行緒的執行而耗盡資源，若是如此，除了改用硬體配備更好的主機外，也可增加多台主機來執行 ACT，甚至購買 ACT 正式的版本，以控管多台主機一起對伺服端作施壓與測試。
微軟的 ACT 能幫助我們測試、擷取和分析伺服端網頁的效能指標與其相關資料，並提供圖形操作介面和豐富的統計數據資料，以將所得到的資料做有系統的組織及彙總。至目前為止我們所談論的內容，壓力測試所得到的數據只能在 ACT 中呈現，但是版工聽說微軟即將於明年推出的 Visual Studio 2005 Team System，即可將測試所得到的效能數據直接顯示在 Visual Studio 2005 中，讓團隊程式開發人員可以直接檢視應用程式的效能測試數據和統計圖表，方便做出判斷並加以處理。因此對效能議題較注重或有興趣的開發人員，可考慮採用該項更進階的工具程式。最後聊個題外話，不論是寫程式還是玩線上遊戲，最好都要注意一下自己的身體，避免過度熬夜很傷肝。
參考文件 :
[1] 胡百敬，2004 年 2 月，「SQL Server 效能調校聖經」，第 3 章，學貫出版社。
[2] 微軟 MSDN 網站。
沒有留言:
張貼留言