SQL SERVER 2000壓力測試 (轉)

worldblog發表於2007-12-12
SQL SERVER 2000壓力測試 (轉)[@more@]

SERVER 2000壓力測試:namespace prefix = o ns = "urn:schemas--com::office" />

 -- 大記錄量,大資訊容量

隨著Microsoft的新一代關係 2000(以下簡稱SQL2K)的釋出,業界紛紛瞄準了它的,尤其是針對於 8的效能比較。在一系列的測試中,SQL2K的的確確沒有辜負對它的期望,獲得了相當不錯的成績,終於肩負起對抗Oracle,搶佔高階資料庫市場的使命。

在關聯式資料庫的應用當中,當隨著數量級或者容量級的資料急劇膨脹,很多資料庫的效能就飛速下降。因此在要求嚴格的應用中,通常Oracle資料庫是作為的首選,然而其高昂的價格卻讓人望而卻步。隨著SQL2K的到來,我們期待著Microsoft的SQL2K在大記錄量和大容量的情況下能有優秀的表現。在此,我們針對SQL2K在這兩方面表現的效能作了測試。

測試計劃:

整個測試過程分為兩個部分,第一部分是資料庫大容量狀態下的情況第二部分是資料庫在大記錄量下的執行情況。為了方便測試,我們編寫了一個進行各種資料庫操作,並進行紀錄。

在兩個部分的測試中,我們分別在空資料庫環境下進行各種資料庫基本操作,並記錄各個操作所需要的時間,然後再插入了大容量/大記錄量的資料後,再作同樣的操作並紀錄操作所需時間。最後對前後的時間進行比較。當然,由於傳輸等問題,可能導致一些誤差,但是這對我們的測試不會有太大的影響。

測試準備:

★  測試環境:

OS: 2000 Server

Database:Microsoft SQL Server 2000

Database Server:ADV2000

★  建立資料庫:

使用“企業管理器”在資料庫上建立資料庫test,並且設定其大小為10GB,以避免在預設容量大小下,隨著資料庫容量增加而導致伺服器動態分配空間的時候引起開銷。

隨後再在test資料庫上建立一個Tab表,包含以下幾個欄位:

欄位名

資料型別

欄位情況

可否為空

id

Int,4

主鍵,自加

不可

name

Char, 10

不可

age

Int,  4

不可

Photo

Image, 16

(表一)

  ★ 並且我們使用 6編寫了一個測試程式,採用ADO介面,連線資料庫伺服器ADV2000。測試程式主要完成一下的功能:

1、  插入2000條資料(insert)

2、  選擇1000條資料()

3、  1000條資料(update)

4、  刪除1000條資料(delete)

5、  插入100,000條帶圖片資料(用於大容量測試)/插入1,000,000條不帶圖片測試(用於大記錄量測試)

測試過程

整個測試過程分為大容量資料測試和大記錄量資料測試:

大容量資料測試:

在大容量的資料測試中,我們透過插入圖片來使資料庫的容量膨脹,所以在以下的所有資料庫操作中,例如插入資料,都是指的插入帶圖片的資料。測試中選擇了一張41,958位元組的圖片,並且大容量測試是在插入100,000條記錄以後的測試,因此我們可以大致估計當時的資料表的容量為 (41958 * 100000) / (1024 * 1024) = 4001.43MB。

首先透過測試程式按順序進行如下測試,在空表中“插入2000條紀錄->選擇1000條記錄->更新1000條記錄->刪除1000條記錄”,並記錄下各操作所需要的時間。測試結果如下圖和表中:

ectratio="t">

(圖一)

Insert 2000條紀錄

Select 1000條紀錄

Update 1000條紀錄

Delete 1000條紀錄

132.781 S

41.94 S

0.841 S

1.552S

(表二)

上面的測試是在空資料表中進行資料庫各種基本操作的測試,並且記錄了所需要的時間。然後我們插入100,000條帶有圖片的紀錄,使資料表的資料量膨脹到4001.43MB,接下來的工作就是測試大容量環境下的各種資料庫操作情況。

(圖二)

同樣按照以上的的步驟進行測試:“插入2000條紀錄->選擇1000條記錄->更新1000條記錄->刪除1000條記錄”,並記錄下各操作的時間,如下:

(圖三)

Insert 2000條紀錄

Select 1000條紀錄

Update 1000條紀錄

Delete 1000條紀錄

139.05 S

42.36 S

0.971 S

2.264 S

(表三)

透過對比,我們發現:

在大記錄量(百萬條記錄得資料量下),對SQL2K的影響並不算大,其效能影響也比較小,從下圖以看出來:

(圖四)

從這個柱狀圖可以反映出在需要大量時間的SQL操作中,SQL2K在大容量資料環境下的效能基本能保持,不會有太多的效能下降。但是從後面兩個只需要極短時間執行的SQL操作從圖中無法反映出什麼情況。

那讓我們透過計算再來看一下了,下面是在大容量資料環境下,同樣操作增加的時間與初始資料庫環境下所需時間的百分比:

Insert 2000條紀錄

Select 1000條紀錄

Update 1000條紀錄

Delete 1000條紀錄

4.72%

1.001%

15.46%

45.88%

(表四)

從表中中可以看出,Update和Delete操作的時候,好像在大容量環境下的效能損失嚴重。但是考慮到,因為存取的資料庫伺服器與客戶端位於不同的機器上,雖然透過100M的內部網連線,但是由於網路的問題,導致了存取中網路的延時。當操作所需要的時間比較大的時候,這一點延時對時間比例影響不大,而一旦操作所需要的時間比較短的時候,這個延時就顯得尤為突出了。

對於Delete操作中的45.55%的效能損失,還有一個原因是,當刪除紀錄的時候,資料庫會重建。當資料量太大的原因下,導致了重建索引耗費了較多的時間。

大記錄量資料測試:

在大記錄量環境下的測試,為了讓大容量測試不影響這次測試,首先我們徹底刪除掉大容量測試中使用的表Tab,並且重新建立一個完全一樣的新表Tab用於此次測試。

這個測試中的步驟和上一個測試基本一樣,同樣測試了空表狀況下的各個基本資料庫操作所需要的時間,但是,這個測試中我們沒有插入圖片,photo欄位沒有插入任何東西,保持為空:“插入2000條紀錄->選擇1000條記錄->更新1000條記錄->刪除1000條記錄”,如下所示:

(圖五)

Insert 2000條紀錄

Select 1000條紀錄

Update 1000條紀錄

Delete 1000條紀錄

16.274 S

0.07 S

0.04 S

0.04 S

(表五)

在大容量資料環境下,我們插入的是100,000條帶有圖片的資料,從而導致了資料量達到了4001MB,而在這次的大記錄量環境下的測試,100,000條資料量可能已經不能滿足我們的需要,我們希望能在更高資料量環境下進行測試,以便於增大添入大數量級資料前後操作效率的差異,因此選擇了插入1,000,000條資料。

(圖六)

完成我們的大數量級的資料插入以後,進行下一步的測試紀錄:“插入2000條紀錄->選擇1000條記錄->更新1000條記錄->刪除1000條記錄”,記錄下每一個操作所需要的時間,如下所示:

(圖七)

Insert 2000條紀錄

Select 1000條紀錄

Update 1000條紀錄

Delete 1000條紀錄

16.574 S

0.05 S

0.05 S

0.051 S

(表六)

比較兩種狀況下的測試結果:

(圖八)

  從第一個操作Insert來看,同樣SQL2K在大記錄量環境下效能損失不大,但是其它幾個操作結果從這個圖中依舊無法表現出來,我們只能透過增加時間百分比來作比較:

Insert 2000條紀錄

Select 1000條紀錄

Update 1000條紀錄

Delete 1000條紀錄

1.84%

-28.6%

25%

27.5%

(表七)

透過增長時間的百分比可以看出在這幾個操作中效能有所損失,但是我們卻無法派出是否是因為這些操作時間太短,因為網路而引起的誤差。

四、測試結果

總結:雖然在測試中,因為很多的SQL操作因為所需要的時間過短,而導致受到網路傳輸的影響。但是我們仍然可以透過所需時間較長的SQL操作進行總結:

無論是在大容量(數GB單位)還是大記錄量(百萬條記錄量)環境下,SQL SERVER 2000的效能都能保持較高的水平。一般情況下的效能損失不到5%,因此完全能夠滿足我們通常的實際應用。

但是因為等條件的限制下,我們無法對更大容量(十GB、百GB乃至TB容量級),更大記錄量(千萬,億級資料量)的環境下進行測試。

總體說來,在普通的企業級應用中,SQL SERVER 2000已經是能夠滿足我們的要求。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-991842/,如需轉載,請註明出處,否則將追究法律責任。

相關文章