動態 Web 應用程序的體系結構決策：性能、可伸縮性和可靠性（摘自MSDN）

 

動態 Web 應用程序的體系結構決策：性能、可伸縮性和可靠性

Gregory Leake
Microsoft Corporation

2000 年 11 月

摘要：本文討論 Doculabs 對 Windows 2000 進行的基準測試，說明不同的體系結構決策如何影響 Web 應用程序的可伸縮性和性能。其中包含對各種部署選項和配置設置的基準測試。

在 MSDN Online 代碼中心瀏覽或下載 Nile.com 代碼示例（英文）。

單擊此處下載 Nile.com 代碼示例（英文）。

目錄

簡介
Nile 應用程序
測試平臺
使用 Active Server Pages 的 Visual Basic 應用程序
完全 ASP 實現方案
Visual C++/ISAPI/COM+ 實現方案
測試
結果
使用/不使用 COM+ 的性能對照
進程隔離級別和性能
通過 Windows 2000 網絡負載平衡向外擴展
組件負載平衡
智能劃分
引入 COM+ 事務之後的效果
動態 SQL 與存儲過程對比
向上擴展與向外擴展對比
總結和性能調整考慮

簡介

近期，Microsoft 僱用 Doculabs 對 Microsoft Windows® 2000 作爲電子商務應用的服務器平臺進行了一系列基準測試。本文就 1999 年 7 月 PC Week 的文章“應用服務器評測”繼續說明基準測試的發現。在早先的 Doculabs/PC Week 的基準測試中，運行在 Compaq Proliant 服務器上的 Microsoft Windows NT® 4.0 擊敗了七種運行在高端 Sun 服務器上的不同 Unix 應用服務器（包括 Sun Microsystems 的 iPlanet）。在 Microsoft 在 PC Week 可伸縮性基準測試中表現出衆（英文）中可以看到 PC Week 上發佈的最初測試結果。您也可以閱讀 Doculabs 對 Windows 2000 的新測試報告：@Bench 測試報告：Windows 2000 的性能和可伸縮性（英文），由 Marianne Pendleton 和 Gautam Desai 撰寫。此文章也包含在示例軟件包中。

在基準測試之後，我們對不同觀衆演示了測試結果。觀衆的反映很好，但經常會提出這樣一些問題：

• 最初的結果是根據 Windows NT 4.0 得出的。Windows 2000 的進步有多大？
  
  
• 我是否應該在 COM+ 組件中使用 Microsoft Visual Basic® 或 Visual C++®？
  
  
• 我是否應該使用 ASP 或 ISAPI 來創建我的應用程序？
  
  
• 管理狀態並保持良好的伸縮性的最佳途徑是什麼？
  
  
• COM+ 事務如何影響性能？
  
  
• 我應該在進程中還是進程外運行應用程序？
  
  
• COM+ 負載平衡對應用程序的可伸縮性有什麼影響？
  
  
• 應該使用動態 SQL 還是存儲過程？
  
  
• 如何使用網絡負載平衡來提高可伸縮性？
  
  
• 如何在負載很重的情況下使我的應用程序保持最高的可用性？
  
  
• 向服務器中增加更多的處理器對性能有多少改善？
  
  
• 我能得到基準測試的源代碼嗎？

本文將要解答這些問題。實際上，本文就是我們在許多技術活動（包括 Tech Ed 2000）所作演示的書面版本。本文的目的是說明不同的體系結構決策如何影響 Web 應用的可伸縮性和性能。本文中包含了一些不屬於 Doculabs 正式報告的數據，因爲我們想花一些額外的時間來對不同的部署選項和配置設置進行基準測試，以便回答上述問題。Doculabs @Benchmark 應用程序的完整源代碼包含在示例中。

Nile 應用程序

Doculabs @Bench 基準測試應用程序名爲 Nile，模擬一個在線書店。我們使用三種方式實現了此基準測試應用程序（按照 Doculabs 所指定的功能）：使用 ASP 頁和 Visual Basic，完全使用 ASP，或者使用 Visual C++ 以及 ISAPI 和 COM+ 組件。

Nile 應用程序是一個很簡單的 Web 應用程序。所有基準測試應用程序都是典型的簡單應用程序，用來測試基礎技術底層結構處理真實應用程序負載的能力。當然，真實的應用程序要複雜得多，並可以和內部的舊式系統進行典型的協作通信，其邏輯比 Nile 中的邏輯更復雜。但 Nile 還是有用處的。它突出了應用程序服務器處理數據庫通信、動態頁面生成和事務的能力。這些都是應用服務器產品的日常任務。

從功能上看，Nile 應用程序是基於 TPC-W 的一個鬆散的程序，TPC-W 是事務處理性能委員會 (TPC) 關於電子商務基準測試的新標準。Nile 應用程序是一個簡單的在線書店應用程序，強調將應用服務器用作產品目錄、相關產品搜索、產品瀏覽、客戶帳戶管理、購物車和訂單事務。在基準測試中，90% 的頁面都是根據數據庫內容動態生成的。Doculabs 指定使用該應用程序，這意味着我們必須遵循許多規則，這些規則限制了使用真實應用程序中已經應用的某些更高級技術。例如，即使某些頁面調用某些級別的緩存，也不緩存數據庫信息。另外，必須在中間層或數據層上對狀態進行管理，即使用單個 Cookie 將客戶端會話映射回各自的購物車。最後一點，此應用程序不考慮安全性。所有用戶均爲匿名用戶，且不使用數據加密。在真實應用程序中，客戶帳戶頁和事務頁毫無疑問將使用 HTTPS。 

我們使用三種不同的體系結構來實現 Nile 基準測試應用程序：

1. 由 ASP 頁激活 Visual Basic 6.0 COM+ 組件。
   
   
2. 用 Visual C++ 6.0 編寫的由 Visual C++ ISAPI 通用接頭激活的 COM+ 組件。
   
   
3. 完全使用 ASP 頁，而不包含已編譯組件/代碼。

示例中包含了這些應用程序的源代碼和安裝說明。

注意：   請參見 Nile.com：COM+ 實現方案（英文）以瞭解有關 Vertigo Software, Inc. 對 Nile.com 的 Microsoft 實現方案所作的修改的討論。修改後的程序示例是使用 Microsoft Windows 2000 中的 COM+ 的多層 Web 應用程序。

測試平臺

測試平臺包括下列硬件：

• 一臺 Compaq Proliant 8500（八個 550 MHz Pentium III 處理器，2 MB L2 高速緩存，3 GB RAM），使用 SQL Server 7.0 數據庫
  
  
• 四臺 CMPQ 8500 Web/應用服務器（均爲八個 550 MHz Pentium III 處理器，2 MB L2 高速緩存，512 MB RAM）
  
  
• 五臺 CMPQ 1850 Web/應用服務器（均爲兩個 550 MHz Pentium II 處理器，512 KB L2 高速緩存，512 MB RAM）
  
  
• Cisco 千兆網絡主幹
  
  
• 100 臺 Dell 客戶端工作站（一個 500 MHz CPU，128 MB RAM），用來產生負載，運行 Windows 2000 Server

圖 1：Microsoft @Bench 測試實驗室

使用 Active Server Pages 的 Visual Basic 應用程序

在 Visual Basic 實現方案中，我們使用了大多數企業開發人員在 Microsoft 開發平臺上使用的各種核心 RAD 技術：Active Server Pages、Visual Basic 6.0、COM+ 和 ADO 2.5，用以進行所有數據訪問。我們使邏輯保持極度簡單，因此沒有複雜的技術，諸如在數據層和表示層使用 XML 和 XSL。您看到的應用邏輯可能類似於現在 Internet 上基於 Microsoft 的多數企業 Web 應用程序。特別要說明，Visual Basic 實現方案具有下列特性：

• 使用 COM+ 的邏輯化三層實現。
  
  
• ASP 激活用 Visual Basic 6.0 編寫的 COM+ 組件。
  
  
• 不使用 IIS 會話對象。
  
  
• 使用 Cookie 存儲從數據庫標識種子生成的客戶端 sessionID（會話標識）。
  
  
• COM+ 組件爲所有數據庫邏輯使用 ADO 2.5。
  
  
• 沒有數據緩存。
  
  
• ASP 從 COM+ 組件取回斷開連接的記錄集以進行格式化或顯示。
  
  
• 使用正確的 ADO 編碼技術；數據庫索引被高度優化；爲所有 SQL 使用 SPROC。

完全 ASP 實現方案

完全 ASP 實現方案的代碼與 Visual Basic 實現方案完全相同，但它完全是用腳本編寫的，並使用 VBScript 類文件來代替已編譯的 COM+ 組件。該方案的目的是展示使用腳本相對於已編譯 COM+ 組件的性能損失。該體系結構仍舊是三層的，所有數據訪問都使用單獨的類文件，而不是業務和表示邏輯。但是，由於所有工作都在腳本中完成，其部署選項少於 Visual Basic/COM+ 版本中的選項。例如，該實現方案不能利用 COM+ 動態負載平衡、COM+ 安全性機制等等。

Visual C++/ISAPI/COM+ 實現方案

此實現方案與前兩個示例完全不同。它的目的純粹是性能方面的，而不是進行 RAD 開發。我們希望顯示出 Visual Studio 6.0 開發工具的靈活性，讓開發人員編寫低級代碼以獲得可能的最高性能。此代碼編寫起來比較困難。但有一個好消息，Visual C++ 組用它作爲練習來幫助設計 Visual C++ .NET。現在，Visual C++ .NET 附帶了名爲活動模板庫 (ATL) 服務器的新功能，它將徹底簡化使用此類體系結構開發應用程序的過程。 

該體系結構使用了瘦 ISAPI 層（激活 Visual C++）和 COM+ 組件（執行所有工作/數據訪問）。數據訪問沒有使用 ADO，而是使用 ODBC API。

如您將要看到的那樣，此應用程序的性能特性與 Visual Basic/ASP 和完全使用 ASP 的版本明顯不同。主要原因有三點：

1. 使用 ISAPI 而不是 ASP 作爲對 IIS 的低級擴展。在此應用程序中沒有激活的服務器端腳本引擎。
   
   
2. 使用 ODBC API 而不是 ADO 進行數據訪問。ADO 是一個很好的數據訪問包裝程序，節省了許多手動編碼工作，但是作爲一個抽象層，它增加了某些開銷。
   
   
3. 使用 Visual C++ 而不是 Visual Basic。C++ 代碼完全是低級語言，更接近於已編譯格式的機器代碼。儘管如此，要牢記 Visual Basic 也被編譯爲本機代碼（從 Visual Basic 5 以來一直如此）。不過已編譯格式的 Visual C++ 代碼的執行效率更高。

當然，所有這些決策要在必要的開發技能和構造應用程序所需的時間之間取得平衡。我想強調一下 Visual Basic 和完全 ASP 應用程序，雖然它們沒有 Visual C++ 應用程序快，但通過服務器羣集也能達到我們意想不到的速度和卓越的可伸縮性。事實上，我們會毫不猶豫地將 Visual Basic 和 ASP 應用程序放到任何或所有運行在最昂貴的 SUN 設備上的非常高端的 UNIX 應用程序服務器上。Visual Basic 和 ASP 技術將滿足 Web 上絕大多數電子商務應用程序的性能和可伸縮性需求。

Visual C++ 實現方案是 Doculabs 在 PC Week 的基準測試的最初 C++ Nile 應用程序的一個改寫版本。在最初的實現方案中，所有代碼都包含在一個 ISAPI DLL 中，是單一的兩層結構。新的 COM+ 應用程序在這一點上更高級，它是一個邏輯化三層體系結構，更易於維護，並提供了更多的部署選項，例如使用組件負載平衡和 COM+ 事務。

測試

在看到真實的基準測試結果之前，有重要的幾點需要注意。首先，我們使用 Quest Software 的 Benchmark Factory 來生成負載並測量性能結果，並在可靠性測試中追蹤錯誤率。要記住，Doculabs 執行重要的測試並審覈結果，但是用來顯示體系結構平衡的後續測試是由 Microsoft 自己在相同實驗室中完成的。

Benchmark Factory 的負載特性與 Microsoft 自己的 Web Application Stress 工具類似。這表明相對較少的客戶端能輕易地在系統上產生巨大的負載。爲確保安全，我們使用了 100 臺客戶端計算機，並確保這些客戶端不會成爲測試中的瓶頸。爲了最大程度地增加系統負載，我們“毫無停頓”地運行所有測試，就象 Doculabs 最初的 Windows NT 4.0 測試（發佈於 PC Week ）和 2000 年 8 月的 Windows 2000 Advanced Server 重新測試一樣。當您查看結果時，牢記這一點非常重要。測試中的一個虛擬“用戶”實際上等於許多個“真實”用戶訪問服務器。據 Doculabs 估算，在不停頓情況下的一個用戶相當於在頁面請求之間有正常用戶延遲情況下的至少十個真實用戶。但這只是粗略的估算。100 臺客戶端計算機上的 Benchmark Factory 向服務器上增加的負載應該比絕大多數 Internet 站點將要經受的負載還要大。

結果

圖 2 描述了最初 Doculabs/PC Week 評測的結果，我們在 Windows NT 4.0 上運行 Nile 應用程序，分別在 Visual Basic/ASP 中和在 Visual C++ 中作爲 ISAPI 應用程序進行測試。在此測試中，Nile 直接與運行在高端 SUN 服務器上、使用 Oracle 8i 數據庫、基於 Java 的應用程序服務器比較。Microsoft Nile 組則使用 SQL Server 7.0 數據庫。

圖 2：最初的 Unix 與 Windows NT 大拼比

此測試是在一年前進行的，那麼現在又有了哪些影響性能和可伸縮性的改進？主要的變化有兩個，其一是使用了 Windows NT 4.0 的換代產品 Windows 2000，其二是使用了具有更快的 Intel Pentium 芯片的新型八路系統。這兩個要素一起使得性能大大增強，下面顯示的是 2000 年 8 月 Doculabs 對 Microsoft Nile 應用程序重新測試的結果：

圖 3：Unix 與 Windows NT 的重新測試比較

下面的圖表顯示向系統中增加用戶時，每個受測應用程序的完整的相對吞吐量曲線。請記住後端硬件和操作系統都已升級，以便達到最佳的結果。硬件從帶四個 500 MHz CPU 的 Compaq ProLiant 6400R 升級爲帶八個 550 MHz CPU 的 Compaq ProLiant 8500。操作系統從 Windows NT 4.0 Enterprise (Service Pack 5) 升級爲 Windows 2000 Advanced Server。

圖 4：最初 Windows NT 4.0 結果與 Windows 2000 重新測試結果 (Visual Basic-COM+/ASP)

圖 5：最初 Windows NT 4.0 結果與 Windows 2000 重新測試結果 (Visual C++/ISAPI)

下一組數據顯示相同的硬件環境下 Windows NT 4.0 與 Windows 2000 Advanced Server 的完整重新測試結果。它真實對比了這兩個操作系統運行 Nile 應用程序的相對性能差異。該數據顯示對於 Visual Basic/ASP 和 Visual C++/ISAPI，在較高負載情況下，Windows 2000 的吞吐量都比 Windows NT 4.0 高約 30%。但是請注意，完全 ASP 版本（在最初 Doculabs/PC Week 評測中沒有測試）的測試結果更加驚人：Windows 2000 比 Windows NT 4.0 高約 100%。產生此差異的原因在於對 ASP 腳本引擎使用了 IIS 5.0 和 ADO。

圖 6：Windows 2000 Advanced Server 與 Windows NT 4.0 (Visual Basic-COM+/ASP)

圖 7：Windows 2000 Advanced Server 與 Windows NT 4.0 (Visual C++/ISAPI)

圖 8：Windows 2000 Advanced Server 與 Windows NT 4.0 (完全 ASP)

有關以製表符分隔的數據列表，以及 Doculabs 在 Windows 2000 和 SQL Server 7.0 上進行故障轉移/可靠性測試的完整討論，請參見 Doculabs 的正式報告。

使用/不使用 COM+ 的性能對比

後面的數據都是在 Windows 2000 Advanced Server 上得到的測試結果，該測試是 Microsoft Nile 組使用相同的設備自己測試得出的，用以說明不同體系結構和部署選項之間的對比。

圖 9 顯示了 Visual Basic/ASP/COM+ 實現方案與完全 ASP 實現方案的性能比較。

圖 9：完全 ASP 版本（VBScript 類）與使用 Visual Basic/COM+ 組件的 ASP

圖 9 顯示出某些有趣的發現。首先，在 Windows NT 4.0 下，我們對開發人員的建議是：已編譯的 Visual Basic 代碼的性能比腳本代碼高。同時，通過向 COM+ 組件中放置邏輯，開發人員可以更好地避免剖析長而複雜的 ASP 頁的“混亂代碼”。但是，完全使用 ASP 實現方案的 Nile 在 Windows 2000 上的實際執行情況和已編譯 COM+ 版本一樣好（甚至更好）。這說明，在 Windows 2000 上，您不再需要爲使用腳本而付出性能代價，就可以獲得和使用已編譯 Visual Basic 代碼一樣的效果。ASP 腳本引擎在 Windows 2000 上運行更快。另外，我們使用 VBScript 5.0 的新功能來創建使用類定義的對象，這樣，代碼就象 Nile 的 Visual Basic 6.0 版本一樣簡潔。實際上，它的代碼是相同的，但是使用了 VBScript 類，而不是 Visual Basic 6.0 類模塊中定義的 COM+ 對象。當然，完全 ASP 版本不能利用 COM+ 的特性，例如安全模型、組件隊列以及動態負載平衡。另外，許多大規模的站點需要使用腳本，因爲腳本便於靈活地升級邏輯，不存在組件版本管理和在產品站點上重新註冊所帶來的問題。有一個好消息，這些選項不再互相排斥。您可以將經常更改的邏輯保存在腳本中，將已固定的邏輯保存在封裝的 COM+ 組件中。

圖 10：Visual C++：從單一 ISAPI 移至 n 層 COM+ 組件

圖 10 顯示了 Visual C++ 應用程序的相似結果。從根本上說，最初的 Nile 應用程序是兩層單一 ISAPI DLL，我們將其轉爲帶 ISAPI 層的 COM+，僅從 Web 站點激活 COM+ 組件。基本情況是使用 COM+ 不會帶來任何嚴重的開銷，並且兩個應用程序的性能非常接近。

進程隔離級別和性能

在部署任何 Web 應用程序時必須回答的另一個問題是有關進程隔離的問題。我們在各種進程隔離級別上對 Visual Basic/ASP/COM+ 應用程序進行了測試，以便說明此決策對性能的重大影響。結果表明，基於 ASP 和 COM+ 的 Web 應用程序的默認的現有進程隔離級別並不理想，應儘可能進行調整。

進程隔離是指將運行代碼劃分到由操作系統管理的不同進程空間中。其基本用意是在 Windows 2000（和 Windows NT 4.0）下，某個進程崩潰時不會影響另一個進程。例如，如果某個 ASP 應用程序是與 IIS Web 服務器 (InetInfo.exe) 進程隔離的，則該應用程序崩潰時，計算機上的 Web 服務器仍然爲其它站點提供頁面——因此不會出現系統範圍的崩潰。但是，進程隔離的缺點是降低了性能。在一個應用程序中跨越進程邊界的代價很高。數據封送將產生大量開銷，並導致大量 CPU 上下文切換。在 Windows NT 4.0 下，這個代價很高，因此所有新建的 ASP Web 應用程序的默認設置都是在與 IIS 相同的進程空間中運行。在 Windows 2000 下，ASP 應用程序的性能有了很大提高，因此操作系統改變了默認設置，使所有新建的應用程序都在與 Web 服務器不同的進程空間中運行。如果您正在對 Windows NT 4.0 和 Windows 2000 執行自己的性能測試，要牢記這一點，因爲不能將 Windows 2000 的進程外（默認）和 Windows NT 4.0 的進程內（默認）作比較。

讓我們看一看 Visual Basic/COM+/ASP 應用程序和進程隔離的三個基本選項。然後我們將討論基於性能數據而建議的途徑。Windows 2000 的第一個選項是將 ASP 應用程序的設置改回 Windows NT 4.0 的默認設置，使所有程序與 Web 服務器在同一進程空間中運行。這是最快、最簡單的選項。該選項還要將所有 COM+ 應用程序的默認設置從服務器激活（所有 COM+ 對象的實例均使用獨立的進程空間）改爲庫激活（在調用應用程序的進程空間中創建 COM+ 對象）。如果您的 ASP 應用程序和 COM+ 組件經過良好測試，並且該應用程序是計算機上僅有的應用程序，那麼這是最佳選項，可以保持性能穩定並支持最大數目的併發用戶。

圖 11：單一進程選項的進程隔離

下一個選項是保留 ASP 應用程序的進程隔離的默認選項，但是將 COM+ 應用程序從服務器激活改爲庫激活。這意味着將在與調用 ASP 頁面相同的進程空間中創建所有 COM+ 對象，但是 ASP 頁面（以及 COM+ 對象）將與 Web 服務器進程隔離。這是比較安全的配置，但是也會降低性能，因爲 IIS 必須在 ASP 和 IIS HTTP 服務器之間封送數據。

對於新的、測試相對較少的應用程序，或者對於運行多個站點和應用程序的服務器而言，這是一個很好的選項。該選項確保當某個應用程序崩潰時，Web 服務器能繼續運行其他應用程序。COM+ 組件中的故障不會導致 Web 服務器自身癱瘓。

圖 12：隔離 ASP/ISAPI 進程的進程隔離

最後一個選項實際上是調入 COM+ 組件的、新建的 ASP 應用程序的默認設置。在這裏，ASP 應用程序被標記爲進程外，COM+ 應用程序（COM+ 組件的容器）被標記爲服務器軟件包。但是在此選項中，您可以看出進程實際上已經分解。每個 ASP 調用都跨越進程邊界，每個激活的 COM+ 組件都跨越另一個進程邊界。這帶來了大量的開銷，對於絕大多數站點而言，是無法容忍的。

圖 13：用 ASP/ISAPI 進程隔離和 COM+ 進程隔離來進行進程隔離

給出這些選項後，下面提供 Nile 應用程序在每個進程隔離配置下的性能數據。此數據是在一臺獨立的 Compaq ProLiant 8500 上得出的。

圖 14：Visual Basic/COM+ 和 ASP 進程隔離變化

很明顯，進程隔離策略對性能造成重大影響。

通過 Windows 2000 網絡負載平衡向外擴展

負載平衡是 Doculabs Windows 2000 測試的一個重要環節。負載平衡允許某個站點在一個服務器集羣上“向外擴展”，這樣就可以通過在後端增加更多副本服務器來輕鬆地提高容量。負載平衡還提供冗餘，使站點具備故障轉移能力，這樣，即使後端的一臺或多臺服務器出現故障（或因維護而需要關閉）時，該站點仍然可供用戶使用。在近期的應用服務器爭奪戰中，大多數應用服務器供應商、出版物和分析家都頻頻提及一個名爲“動態負載平衡”的特性。但是，動態負載平衡是用在極少數大規模 Web 站點上的特性，而多數大規模站點進行向外擴展的主要途徑還是使用更簡單的網絡級負載平衡。在這種網絡級負載平衡中，外來的 IP 請求被簡單地路由給副本服務器，然後基於其處理能力動態分佈邏輯，而不是試圖獲得應用程序中的單個組件。爲什麼這項技術應用更廣呢？因爲網絡負載平衡 (NLB) 簡單，易於設置，並能順利地完成任務。另外，多數應用服務器使用專門的黑盒算法在多個應用服務器上分配負載，有些算法能很好完成任務，但許多則不能完成。設置和維護這樣的數據中心可能需要討論，特別是當分配/路由邏輯十分複雜，並且可能在系統中產生瓶頸的情況下。 

在後端服務器的羣集上分配負載時，網絡負載平衡比動態的組件級負載平衡更爲通用。它既可以通過提供 NLB 的硬件解決方案（例如 CISCO Local Director）實現，也可以通過軟件解決方案（例如簡單的循環 DNS）實現。完善的解決方案不存在單點故障。簡單的循環 DNS 易於使用，但並不完美，因爲如果羣集中的一臺服務器出現故障，外來的請求仍被路由給該服務器。因此，如果您有三臺服務器，而其中一臺被關閉，則客戶端上的三分之一請求將出現故障。Windows 2000 Advanced Server 內置了 NLB 服務，在進行任何 Web 站點設計（Intranet 或 Internet）時，都應該考慮這一重要特性。通過 Windows 2000 NLB 服務，您可以輕易地將所有外來的網絡請求分佈到後端服務器的羣集上。該方案不存在單點故障。一個服務器關閉後，所有請求立即被轉移給其他可用的服務器，這些工作可在一秒以內完成。在 Doculabs 的基準測試中，我們使用 Windows 2000 NLB 作爲服務器的主要負載平衡機制，在四臺服務器（測試的最大數目）上爲 Visual Basic 應用程序提供了線性擴展（並在可靠性測試中進行故障轉移）。

NLB 爲 Visual C++ 應用程序提供了兩臺服務器上的線性擴展，但因爲 Visual C++ 應用程序每秒處理的動態頁面更多，所以數據庫負載級別更高。因此，如果在中間層的兩個服務器上添加第三臺和第四臺服務器，在吞吐量性能方面的收益將遞減。此時，SQL Server 7.0 數據庫的 CPU 使用率超過 85%，而關鍵因素也不再是中間層，而是數據庫。繼續擴展 Visual C++ 應用程序的唯一途徑是將負載分配到多個數據庫服務器上。請看下面的數據：

應用程序	一臺服務器上的最大吞吐量	四臺服務器上的最大吞吐量
Visual Basic/COM+/ASP	每秒 987 頁	每秒 3,865 頁
Visual C++/COM+/ISAPI	每秒 2,943 頁	每秒 8,452 頁

形象地說，每秒 8,452 個頁面等於每天處理 730,252,800 個頁面，即 Internet 業務量最大的站點 Yahoo 在繁忙時全天業務量的兩倍。在基準測試中，90% 的 Nile 頁面涉及到數據庫請求，且沒有中間層緩存。在這種情況下，一個 SQL Server 7.0 數據庫服務器就可以完成任務。當然，Nile 是一個非常簡單的應用程序，但它可以解釋，爲什麼在 TPC-C 最佳結果中涉及絕對性能的前六項中，SQL Server 佔據四項，其中包括絕對性能第一名。

要進一步向外擴展 Nile Visual C++ 應用程序，需要在多個服務器上對數據庫進行劃分，或者通過“向上擴展”的途徑來完成，即在更快的計算機上運行 SQL 數據庫，例如在新型的 Compaq 和 Unisys E7000 上，這些計算機支持最多 32 個 CPU。同時，使用 SQL Server 2000 中的新特性分佈式分區視圖 (DPV) 可以進一步擴展，方法是在並行工作的多個後端服務器上劃分某些數據庫表。

組件負載平衡

Windows 2000 Advanced Server 提供了網絡負載平衡，而 Application Center 2000 將使用組件負載平衡 (CLB)，它是動態的負載平衡，用於應用程序中的獨立遠程 COM+ 組件。此特性非常有用，因爲它爲組件的遠程處理提供透明編程。使用 COM+ 來創建邏輯 n 層應用程序的一個原因是：在部署物理兩層或物理 n 層數據中心體系結構方面，它能爲您提供更大的靈活性。換句話說，您可以在本地調用的 Web 服務器上運行 COM+ 組件，也可以將 Web 服務器以外的某些或所有組件分佈到應用服務器的專用層上。

但是，最主要的原因是，從 Web 服務器上以進程外方式運行組件將降低性能，同樣，在 Web 服務器以外遠程管理組件也降低性能，因爲由每個組件交互和跨網絡 COM+ 數據封送都將產生額外的網絡躍點。然而，許多客戶出於不同原因仍需要在 Web 服務器以外遠程管理邏輯，包括在 Web 服務器和接觸被保護的子系統（諸如 SAP R/3 等內部 ERP 系統，以及客戶數據庫等）的組件之間加入額外防火牆的能力。

我們讓 Doculabs 在 Nile 應用程序上執行了測試，使用三層物理數據中心體系結構來測量遠程管理 COM+ 組件的性能影響。圖 15 說明，Visual C++/ISAPI/COM+ 應用程序在 Web 服務器上以進程內方式運行所有 COM+ 組件時與通過網絡遠程管理單一應用服務器上的所有組件時存在明顯的性能差異。現在，如果引入更多服務器，吞吐量曲線將得到改善（在這種情況下，瓶頸是單一應用服務器）。但是，要想獲得與本地、進程內組件相同的性能級別，則需要更多的硬件。

圖 15：Visual C++ COM+ 對象的本地和遠程管理

智能劃分

我們是否應該在 Web 服務器以外遠程管理所有組件？這個關鍵問題的答案是否定的。實際上，如果在您的數據中心和應用程序自身中正確設置了安全性，在 Web 服務器以外遠程管理單獨的 COM+ 組件沒有安全性優勢。但是請考慮構成 Nile 應用程序的組件並引入應用邏輯的“智能劃分”觀點。實際上，Nile 應用程序訪問的絕大多數組件都與服務器上的 GUI 型操作有關——根據目錄瀏覽、相關產品搜索等的結果動態生成 HTML 頁面。這些是隻讀操作，一般適用於只讀的產品目錄（可更新的主目錄可能是不在 Web 上發佈的內部系統）。

Nile 應用程序中的其他組件則接觸更爲敏感的數據庫信息。例如，處理對客戶數據庫交互（讀和寫）的組件，或執行實際訂購事務的組件。如果安全性是使用 Web 服務器外遠程管理邏輯的主要原因，請考慮劃分您的類文件，這樣就可以遠程管理真正需要的組件，而不用遠程管理所有組件（包括只是用來生成 HTML UI 的簡單組件）。對於 Nile 和多數其他應用程序，有三個因素使得智能劃分和“選擇性遠程管理”非常重要：

1. 大多數組件涉及到生成 UI 以將許多數據傳回客戶端，從數據庫獲取產品信息，生成後續 HTML，然後將其傳回給 Web 服務器以便發回到客戶端。遠程管理這些組件將帶來許多數據封送開銷，並對性能造成極大影響。
   
   
2. 另一方面，用於更新客戶記錄或進行定購的組件往往不向客戶端傳回大量數據——可能會傳回某種訂單確認號，但沒有大量要顯示的數據記錄。遠程管理這些組件不會對性能造成相同的影響。
   
   
3. 如果您看一看典型 Web 站點的訪問模式，就會發現絕大多數訪問都是查看頁面以進行產品瀏覽、搜索等，而進行訂購或更新重要客戶信息的頁面訪問量很少。

結合這三點可以得出結論。您可以適度地遠程控制接觸系統敏感部分的組件，而不會像遠程管理 GUI 組件那樣付出很大代價。我們之所以要遠程管理這些組件，還因爲它們經常長時間運行，與多個內部系統接口，同時還可以降低 Web 服務器自身的某些處理負擔。

對於 Nile，我們以這種方式智能地劃分代碼，然後應用特定的規則來決定是在 Web 服務器上單獨運行這些組件，還是使用 CLB 在應用服務器的專門羣集上運行。首先，如果該組件執行任何事務/寫入數據庫，則對其進行遠程管理。其次，如果組件接觸（讀或寫）任何客戶數據庫，則對其進行遠程管理。如果該組件僅僅接觸只讀產品數據庫以便響應瀏覽和搜索請求，則可以將其保持在本地運行，作爲 Web 服務器的擴展。在基準測試中，Doculabs 混合使用了六種不同的用戶配置，用以代表電子商務站點的典型使用模式：某些配置進行瀏覽/搜索，某些配置進行定購，某些配置創建或更新客戶帳戶，某些配置則執行不同的混合操作。圖 16 是智能遠程管理的應用程序與全部本地運行的應用程序的性能對比圖表：

圖 16：智能遠程處理和全本地運行 COM+ 對象

可以看到，與遠程管理系統中的所有組件相比，智能遠程處理的影響很大。此測試的目的就是讓您仔細考慮遠程管理組件的原因，並明智地決定哪些組件需要遠程管理，哪些組件要保持本地運行。

我們最後測試的配置爲多個 Web 服務器以及運行在智能遠程管理配置（上述每個標準）中的多個專門應用服務器。我們採用一系列 Compaq ProLiant 1850r 服務器，作爲 Visual Basic/COM+/ASP 實現方案的前端 Web 服務器後的專用應用服務器運行。在這種情況下，所有 Compaq Proliant 8500 都通過 NLB 組成羣集，作爲到應用服務器的冗餘 COM+ 路由器，沒有單點故障。1850r 服務器使用 CLB 組成羣集，僅僅用於運行在 Web 服務器以外分佈的 COM+ 組件。同時，此層上沒有單點故障，因爲與 NLB 一樣，CLB 能夠在應用層中的一臺或多臺服務器停機時提供故障轉移。下面是結果：

圖 17：智能分佈和全本地對象

請注意，分佈式組件負載平衡配置的吞吐量曲線下降得比全本地配置要快。這是由於應用層（1850r 服務器）在超過一定點後就達到飽和。添加更多的專用應用服務器可使這條藍線變得平直，並與全本地吞吐量曲線保持一致。但是，這需要在應用層中添加更多硬件。

引入 COM+ 事務之後的效果

COM+ 提供的主要服務之一是對組件間分佈事務的支持。給出 Nile 性能數據以後，我們經常聽到這樣的問題：“進行基準測試時，事務是打開還是關閉的？”答案是：對於最初的 PC Week 評測，事務是關閉的，因爲它不是一個基準測試標準，並且其他供應商的應用程序中也沒有事務處理 (TP) 監視器。

讓我們來看一看，如果在 Nile 應用程序中打開對 COM+ 組件的事務支持，將這些組件標記爲“要求事務”，那麼會發生什麼。這種情況下，對每一個組件調用，它都將調用 Microsoft Distributed Transaction Coordinator。可想而知，這將爲系統添加開銷。回到有關基於智能劃分的遠程管理組件的討論，對於事務支持的問題，其邏輯是類似的。Nile 中的所有組件都涉及真正的數據庫事務嗎？回答是否定的。實際上，沒有任何組件真的需要 COM+ 事務支持，因爲應用程序中的事務很簡單，僅針對單個數據庫，可以很容易地在存儲過程中直接進行處理。但是，我們進了一步，以智能方式劃分了 Nile 的邏輯，從而能夠爲所有對訂單和客戶數據庫執行寫操作的組件啓用事務支持，但仍關閉對執行簡單選擇語句的組件的事務支持。圖 18 顯示了這種策略的效果：根據情況智能地使用事務，而不是盲目爲系統中的所有 COM+ 組件打開 COM+ 事務。圖 18 以運行在一臺 Compaq ProLiant 8500 Web/應用服務器上的 Visual C++ 應用程序爲例。

圖 18：智能地使用 COM+ 事務

另外，您還要仔細考慮哪些組件需要事務支持，並智能地劃分您的類文件以便可以有選擇地將組件標記爲“要求事務”。

動態 SQL 與存儲過程對比

如果預先知道 SQL 語句（而不是在運行過程中由使用/應用邏輯動態構造），我們建議在絕大部分情況下都使用存儲過程。使用存儲過程，而不是在應用程序中直接嵌入 SQL 字符串，這使系統更易於維護。同樣，SQL Server 將有一個預編譯的查詢計劃，按照這個計劃執行的速度比動態 SQL 快。圖 19 用圖表對比了 Nile ASP 應用程序使用全動態 SQL 與存儲過程的不同情形：

圖 19：對 Nile ASP 應用程序使用全動態 SQL 和存儲過程

向上擴展與向外擴展對比

最後，我們分別在八個 CPU 和四個 CPU 的 Windows 2000 系統上運行 Nile 應用程序，測試向上擴展帶來的影響。圖 20 中的數據表明了一個關鍵問題——不能期望系統添加了處理器後性能會有線性增長。向外擴展（添加副本計算機）通常比向服務器添加更多處理器的效果更好。但是，向上擴展和向外擴展都非常重要。通過向上擴展，您可以顯著減少處理用戶負載所需的服務器數目，因而降低了數據中心中的管理成本。另一方面，通過向外擴展，您能夠以較低成本獲得大幅擴展，以及對高可用性站點的故障轉移支持。通過新的 Windows 2000 Data Center Server，可在最多 32 個 CPU 的系統上運行，並可將一些 CPU 專門分配給某個應用程序，從而使服務器獲得更好的穩固性。另外，如果某個應用程序的 CPU 利用率達到飽和，Windows 2000 Data Center Server 可以自動重新配置處理器，爲該應用程序分配更多的 CPU。

圖 20：從四個處理器擴展到八個處理器的 Windows 2000 系統

總結和性能調整考慮

下面列出了一些最重要的步驟，在創建和調整 Nile 實施方案時需要執行這些步驟：

• 加上負載，測試和調整應用程序。
  • 確定性能目標。
    
    
  • 發現和消除瓶頸，直至達到目標。
• 數據庫調整最爲重要。
  • 適當的索引非常關鍵。
    
    
  • 監視 SQL Server CPU 利用率。它在中度負載情況下應較低，輕度負載時則應很低。
• 適當配置數據庫（例如，根據事務記錄，使各 RAID 控制器並行操作，併爲數據隔離各個設備）。
  
  
• 使用無狀態數據庫操作並始終使用斷開連接的記錄集。
  
  
• 使用適當的 ADO 編碼技術（請參閱 MSDN 上的 FMStocks 2000 和 Nile 示例）：

  rs.CursorLocation = adUseClient
  rs.Open cmd, , adOpenForwardOnly, adLockReadOnly 
  

• 避免：
  • 單行記錄集（用盡參數），adExecutenoRecords。
    
    
  • 大記錄集（數百條記錄可以，數千條則不行）。
• 在進程內或以進程隔離的形式運行 ASP 或 ISAPI，但儘可能在進程內運行 COM+ 軟件包（庫軟件包）。
  
  
• 使用 Windows 2000 網絡負載平衡。
  
  
• 不要盲目地用 CLB 分佈所有 COM+ 組件，而是使用智能準則。許多對象並不需要分佈，包括那些只涉及只讀數據的 UI 對象。
  
  
• 合理使用 COM+ 事務。
  
  
• 關閉不使用的 COM+ 特性，例如事件和狀態、同步、事務和 JIT。
  
  
• 不要過分寄希望於中間層緩存。它們可能不是必需的。
  
  
• 對於用戶狀態，儘可能使用數據庫或客戶機程序，避免使用 IIS 會話對象和應用程序對象。
  
  
• 對長時間運行的操作，如訂購和與老式系統交互，請使用異步操作（COM+ 鬆耦合事件，消息隊列）。