ADO資料庫訪問的最優方法

來源:互聯網
上載者:User
ado|訪問|資料|資料庫   幾乎所有關於ADO資料庫訪問效能分析的文章,都認為二進位組件的效能總是超過解釋執行的ASP代碼。事實上,這是錯誤的。從本文的測試結果可以看出,有些時候ASP代碼的效能遠遠超過了組件。
     
一、引言

  “地球是平坦的...”;
  “太陽繞著地球轉...”;
  “總是通過組件訪問資料庫...”,


  上面三個命題有兩個共同的特點:首先,它們都曾經被認為是正確的;其次,這三個命題實際上都是錯誤的。

  我們都已經讀到過無數的文章建議在Internet應用中用組件封裝商務邏輯和進行資料庫訪問,但有關這種技術的實際效能資料卻很少看到。隨著Windows 2000的發行,IIS平台特別是ASP的效能表現也有了顯著的提高。由於先行綁定(Early-binding)內部對象、模板緩衝等諸多改進,在通過ADO訪問資料庫、格式化並輸出記錄集等各個方面,ASP都有一流的效能表現。

  從本文測試結果可以看出,ASP在ADO資料庫訪問、記錄集格式化方面勝過組件,而且在某些情形下兩者的差異達到了難以置信的程度。對於大多數Internet應用來說,效能總是首要因素,所以在根據傳聞或書本知識確定最優方案之前,使用測試載入器對方案進行完整的測試是很重要的。

  在進行測試之前,本文的所有三組代碼(ASP,VB和C++)都經過了最佳化。為了確保參與測試的代碼其編碼方法和測試結果都是各自領域中最優的,它們都經過了多次測試。某些最佳化工作尚未進行,這是為了讓代碼更真實地反映出實際應用環境中可能出現的典型情況。

二、測試環境

  本次測試只在Windows 2000平台上進行,在Windows NT平台上測試結果可能會有很大的不同,所以測試所得到的結果不適用於Windows NT平台。下面是本次測試所用系統的示意圖及其說明:




  由於測試客戶機和Web伺服器、資料庫伺服器所處的物理位置不同,客戶機通過三個Cisco 2924交換器串連到Web伺服器。所有這些機器都在同一大樓內,但伺服器位於資料中心,而測試客戶機位於另一個房間,客戶機通過一個400Mb Fast EtherChannel串連到資料中心的交換器。

  在這個配置下,測試案例的網路延遲所引起的開銷是非常小的。在日常運行中交換器之間的流量總是小於其能力的5%。

三、測試代碼

  由於這是一個從ASP、VB組件、C++組件通過ADO進行資料庫訪問的測試,因此測試代碼的功能限於從結果記錄集建立一個表格。所有測試程式都可以從本文後面下載。這些程式的執行流程都類似,具體如下:


  使用ODBC DSN建立/開啟一個資料庫連接
  建立一個Command對象(設定其類型為adCmdStoreProc)
  指定返回記錄數量的參數
  執行命令,返回記錄集
  關閉記錄集和串連,釋放這些對象佔用的記憶體。
 可以證實上述方法具有最快的資料庫訪問速度,這是因為:


  預存程序訪問速度要比動態SQL快,即使啟用了SQLServer 7.0的SQL計畫快取功能也一樣。
  使用Command對象並顯式地指定參數要比傳入一個查詢字串快得多,這是因為此時OLEDB提供者無需分析查詢類型以及所有傳遞給預存程序的參數的類型。
  ODBC串連池避免了為每一個開啟命令建立物理串連。每次關閉串連將把已開啟的串連釋放回串連池。
結構,這是為了能夠讓測試程式更加精確地類比出實際的記錄集處理過程。   返回給用戶端的HTML代碼是從一個兩列的記錄集建立的<table>結構。所有測試程式都用while迴圈遍曆記錄集,而不是用速度更快的GetString方法直接從屬記錄集資料得到<table>結構,這是為了能夠讓測試程式更加精確地類比出實際的記錄集處理過程。

  測試所用的預存程序從表中提取記錄,返回記錄的數量以參數形式傳遞給預存程序。

  測試以多種不同的記錄數量和線程數量(並發請求數量)運行。記錄數量的範圍從0行到100行,但沒有測試超過100行的返回記錄數量,這是因為考慮到大多數設計良好的Web應用不會出現如此大規模的記錄集資料提取和格式化操作。

  線程數量的變化範圍從25到2000。在所有測試中,IIS/COM+伺服器的處理器利用率大於99%,但線上程數量較少時(25,50),ASP隊列長度非常小(或為0)。雖然這些測試也線上程數量設定為1、5、10時運行過,但除了處理器利用率之外,這些線程數量的測試沒有表現出任何本質上的不同。

  測試所用的工具是Microsoft的Web Application Stress Tool,測試指令碼的基本設定如下:


  所有測試指令碼均在網路利用率最低的時候運行。此外,測試期間IIS/COM+伺服器和SQL Server上都沒有進行其他動作。

  IIS的“應用程式保護”設定成“低”,這使得應用運行具有最好的效能,特別是對COM+庫應用的測試來說尤其如此。這個設定同時也允許了所有任務在inetinfo進程內運行。

  參與測試的五種程式為:ASP,VB組件(COM+的庫應用),C++組件(COM+的庫應用),VB組件(COM+的伺服器應用),C++組件(COM+的伺服器應用)。

  在所有測試程式中,測試客戶機的負載一直沒有超過35%的處理器利用率,而且記憶體佔用也很少。

  有部分最佳化工作沒有做,這是為了讓測試代碼更好地反映出當前的主流應用。例如,本文測試利用ODBC系統DSN建立資料庫連接,把串連改用OLEDB的SQL Server提供者將使整體效能提高大約5-10%。

四、測試結果

  也許你已經從本文的題目猜出本次測試的獲勝者應該是ASP了。下面我們來看看具體的測試結果,探討從這些測試資料得到的結論。

  本次測試的主要統計項目如下所示:




  第一組測試中記錄集的記錄數量設定為10,線程數量在25到2000之間變化。效能的主要度量標準,即Requests per Seconds結果如下所示:



  從上圖可以看出,ASP在效能上比和它最接近的對手VB (In Proc — 進程內,即COM+庫應用)平均快30%,比其他方法要快2倍以上。值得指出的是,VB(In-Proc)的效能隨著線程數量的增加而略有增加。然而,當線程數量超過大約250之後,TTFP和ASP Requests Queued已經高得不再對單個伺服器的正常操作具有任何意義。實際上,許多人會認為即使是250也太高了。因此,在記錄數量更多的測試中線程數量最大值不超過250。

  測試載入器的指令碼運行不產生任何延遲。因此,只要對某個線程的應答一到達,新的請求總是立即發出。

  在分析記錄數量更多的測試結果之前,我們先來看看其它兩個測試單位TTFB和Hits的測試結果。



  正如我們可以預料的那樣,ASP在所有線程數量配置下都具有較快的TTFB。下表比較負載的增加對ASP Requests Queued以及相應的TTFB的影響,所有資料都以Requests Queued -TTFP形式給出,TTFB仍舊以毫秒計。




  可以看出,當負載高達一定程度(~50-100線程範圍)時就有必要加入更多的伺服器來分擔流量。不過本文測試仍舊包含這些高負載的情形,這是為了觀察是否有可能出現不同的變化。

  最後一個效能度量標準hits的測試結果也顯示出和其餘測試相同的傾向,ASP的表現仍舊是最優秀的。

  下一個測試步驟是觀察當記錄集的記錄數量增加時各個測試程式的效能表現。這裡所測試的記錄數量包括:20,30,50,和100。如果你讀過大量這方面的文章,可能會猜想由於記錄數量的增加處理負載也隨之增加,組件將表現出更好的效能。然而,事實並非如此。記錄數量逐步增加時ASP仍舊保持著對其他各種方法的領先優勢。下面是不同線程數量平均後的測試結果。




  即使增加了記錄集的記錄數量,ASP與其他幾種方法之間的效能差異也沒有什麼改變。完整的測試結果可在本文附錄A找到。如果你有空的話,不妨對其他感興趣的問題也進行同樣的測試。本文測試用的所有代碼均在附錄B內提供。你可以利用這些代碼自己進行測試,或者如必要的話進行一些修改。

五、結果分析

  總地看來,在Windows 2000平台上沒有一種採用組件的方法能夠在純ADO操作的效能上超過ASP。雖然以COM+庫應用形式啟動並執行組件相比之下更接近ASP(而且也應該如此),但它們與ASP表現出的效能相比仍略有不足。事實上,即使是進程內啟動並執行VB組件的效能也比ASP的差30%。然而,為了在應用所啟動並執行組件產生錯誤時保護inetinfo進程,許多應用仍舊在一個專用的服務進程(dllhost.exe)內運行它們的COM+應用,在這種常見的情況下,ASP可以提供2比1的效能優勢!

  我們希望本文已經成功地說明了這樣一個問題:在一個Internet應用中利用組件進行資料庫訪問並非一定是最好的方案。務必在深入實施某個方案之前進行完整的測試,這一點極其重要,因為該方案的最終結果可能會和你所設想的(或你所看到、聽到的)完全不同。

  如果Internet應用的規模屬於中等或比較大,效能將成為首要的考慮因素,比代碼的可重用性更為重要。但現實當中主要的應用程式很少(如果有的話)同時也是效能方面的最優方案。

  當然,使用組件也有它的好處。組件往往是封裝某些類型的商務邏輯的最好選擇,特別是在跨系統整合的應用中。然而在有些情形下這似乎走入了一個極端,返回來更深入地瞭解一下現有的技術平台、根據應用的業務情況真正地理解資料的處理、彙集和傳輸過程,這才是明智的。許多時候我們會發現奧鏗剃刀原理掌握了真理:在涉及到複雜的系統時,最簡單的解決方案往往就是最好的解決方案(而且很可能是最容易測量的方法!)。



相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。