ADO數據庫訪問的最優方法

　　幾乎所有關于ADO數據庫訪問性能分析的文章，都認為二進制組件的性能總是超過解釋執行的ASP代碼。事實上，這是錯誤的。從本文的測試結果可以看出，有些時候ASP代碼的性能遠遠超過了組件。
　　 　　
一、引言

　　“地球是平坦的...”；
　　“太陽繞著地球轉...”；
　　“總是通過組件訪問數據庫...”，


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

　　我們都已經讀到過無數的文章建議在Inte.net應用中用組件封裝業務邏輯和進行數據庫訪問，但有關這種技術的實際性能數據卻很少看到。隨著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隊列長度非常?。ɑ驗?）。雖然這些測試也在線程數量設置為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應用的規模屬于中等或比較大，性能將成為首要的考慮因素，比代碼的可重用性更為重要。但現實當中主要的應用程序很少（如果有的話）同時也是性能方面的最優方案。

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

　　雖然本文只涉及了有限的ADO數據庫訪問操作，以更復雜的腳本和組件所作的類似測試也得到了同樣的結果。如果你使用的是Windows 2000平臺，顯然你應該考慮對方案的性能按照本文說明進行廣泛的測試。如果你的終極目標在于性能，你會發現自己把一些組件替換成了ASP?；蛟S連你自己也會對此吃驚。

原文轉自：http://www.kjueaiud.com