網站壓力測試

現在越來越多公司建設自己網站或替客戶建設網站, 這些網站提供一些資料庫應用程式, 讓客戶查詢. 但很少公司知道這些應用程式可以支援多少用戶同時查詢, 當花費了大量資金做宣傳後, 因為這些系統無法支援很多客戶同一時間來訪, 或要客戶等待太長時間, 而損失了大量金錢和客戶.

最好的一個例子就是會考放榜當日, 為學生提供一個網站, 讓學生查詢成績. 但在指定時間內, 成千上萬的學生同一時間用這網站查詢自己的成績, 造成網站大擠塞, 學生需要等十幾分鐘才可以查獲結果, 也有些學生無法連線, 造成很多不便和令學生大失所望.

為了避免以上問題, MemDB推出網站壓力測試服務, 運用一些工具, 製造成千上萬的查詢要求, 尋找這些資料庫應用程式最多可以同一時間支援多少客戶, 從而改善系統, 支援更多的客戶. 在問題未發生前, 做好足夠的準備, 提早解決.

以下是這服務的流程:

1) 客戶聯絡我們, 我們會有專人在電話或上門了解他們的網上資料庫應用系統.
2) 為客戶設定測試的範圍和報價.
3) 在指定的測試範圍內, 進行測試.
4) 提交報表, 結果和建議.

如果需要, 我們也會為客戶編寫程式, 令更多的客戶可以同一時間使用網上資料庫應用程式. 以下是我們如何為客戶進行網站壓力測試和改善系統的例子.

一間從事產品銷售的公司, 建設了一個網上資料庫應用程式, 在網站向客戶提供查詢產品資料功能. 同一時間內, 三個以下的客戶使用這系統, , 平均等候時間在三秒內, 十個客戶時, 平均等候時間需要十秒. 這公司想知道為何這系統會這樣慢, 也想了解這系統最多可以支援多少客戶同一時間使用, 作為日後發展的參考數據.

當這間公司聯絡我們, 我們會用電郵, 電話和上門了解現在狀況, 到他們的網站了解這系統. 這系統使用的資料庫是 Access, 作業系統是 Window 2000 Server, 網上伺服器是 IIS , 利用 ASP 和 ODBC 作介面連接資料庫. 這系統除了查詢產品資料功能, 也有其他功能, 要測試所有的功能需要時間很長, 費用也會很高. 因為最常和最多客戶同一時間使用的功能是查詢產品資料, 所以我們建議首先測試這功能.

設定測試的範圍, 報價和接受報價後, 我們開始準備測試. 我們可以在他們的系統直接測試, 但這樣可能影響其他客戶使用和測試的結果. 在這裡有兩個辦法, 第一就是暫停其他客戶在指定時內使用這系統, 第二就是使用另一部電腦, 所有功能和設備都必須和使用中的系統一樣. 這個公司覺得第二個辦法需要購買和安裝另一部電腦, 費用較高, 另外, 這系統在星期六下午的使用率不高, 所以選擇在某一個星期六下午進行網上壓力測試.

在進行網上壓力測試之前, 我們需要作足準備工作, 如以下圖案. 右邊是需要測試的網上資料庫應用系統 (以下簡稱應用系統), 左邊是測試系統. 首先測試系統會記錄查詢功能的所有參數, 然後這測試系統可以在同一時間提交多個查詢到應用系統, 開始時我們會同一時間提交三個查詢, 為時三分鐘, 測試安裝是否成功, 是否可以獲得需要的結果. 因為我們只提交三個查詢, 不會對應用系統和客戶有太大的影響, 所以這些準備工作可以在平日去執行.

到了指定的測試日期, 因為所有準備工作已完成, 我們可以即時進行壓力測試. 首先, 我們利用測試系統, 在三分鐘內, 同一時間提交十個查詢. 在這三分鐘內, 測試系統會不斷提交十個查詢, 情況就和同一時間內不斷有十個客戶向應用系統提交查詢一樣. 這測試系統會記錄平均回應時間, 同時間我們也會記錄應用系統電腦 CPU 和 記憶體的使用率.

如此類推, 我們同一時間提交二十, 三十, ..., 至一百個查詢, 每個工程為時三分鐘. 等到平均回應時間到了一個不可接受的長度為止.

完成測試, 我們會為這公司編寫一份詳盡的報告. 以下是其中一個圖案報表:

從以上的圖案, 可以知道同一時間有10個客戶向應用系統提交查詢, 每個客戶平均需要等10秒, 才可以得到查詢結果. 40個客戶平均需要等29秒, 100 個客戶平均需要等150秒. 如果這公司應為客戶最多只可以等30秒, 那麼這個應用系統最多可以支援40個客戶同一時間查詢.

同一時間我們也提供應用系統電腦 CPU 和 記憶體的使用狀況, 在100個客戶的時候, CPU的使用率是70%, 記憶體的使用率是30%, 所以 CPU 和記憶體都不是這系統的瓶頸 (Bottleneck), 相信磁碟存取 (Disk Access) 才是這系統不能支持100個客戶同時間使用的原因.

要解釋這個原因, 必須了解這應用系統的流程. 當客戶在瀏覽程式 (如 Internet Explorer) 提交查詢, 這個要求會提交到網上伺服器 IIS, 然後 IIS 執行 ASP 程式, ASP 利用 ODBC 連線到資料庫 (Access), Access 從磁碟裡取得資料, 把結果傳送到 ASP 程式, ASP 程式再把結果傳送給 IIS, 再經 IIS 傳送到客戶瀏覽程式, 如下圖:

從以上的流程, 非常容易了解為何應用系統不能同時間支援100個客戶. 第一個原因是一個查詢涉及三個程式 (IIS, ASP 和 Access), 資料需要傳送多次. 第二個原因是要執行 ASP 和 用 ODBC 連線到 Access, 這些 "額外工作" 令到系統更加慢. 最後一個原因是每一個查詢都需要從磁碟裡取得資料, 大大降低效率. 所以要改善這個系統, 可以從這三個原因開始, 這正是我們的核心服務.

我們建議這間公司使用MemDB提供的網上解決方案, 把所有資料存放在記憶體資料庫內, 並使用我們的網上伺服器, 把資料庫和網上伺服器整合在一個程式上. 當客戶在瀏覽程式提交查詢, 這個要求會直接提交到這個程式, 程式即時在記憶體取得資料, 而無需連線資料庫和任何磁碟存取, 把結果直接傳送到客戶的瀏覽程式, 這可以大大提高系統效率, 增加同一時間使用人數, 如下圖:

我們向這個客戶示範了記憶體資料庫系統MemDB網上會計系統, 說明如何整合網上伺服器和記憶體資料庫. 要把這公司整個系統從新編寫需要很長時間, 所以我們建議先把 Access 的資料移轉到記憶體資料庫和只提供查詢功能. 完成新系統後, 我們會為新系統再次進行網上壓力測試, 保證我們的系統在100個客戶同時使用時, 平均回應時間會少過10秒才收費用.

最後我們也為這客戶完成這個系統, 當然達到指定的要求. 我們更為這公司完成整個系統, 在 1000 個客戶同時間查詢時, 平均回應時間也少過30秒.

隨著互聯網的發展, 流動電話的普及, 系統需要同一時間支援的人數不斷增加. 你是否也想了解你的網上資料庫系統可以同一時間支援多少客戶嗎? 我們有豐富的經驗和知識, 也能為你提供高速的記憶體資料庫系統的解決方案, 更改或從新編寫網上資料庫應用系統. 有興趣歡迎與我們聯絡.

 

版權 © 2001MemDB所有 不得轉載.