網路基礎結構

提供 ASP.NET 應用程式的延展性

Iqbal Khan

簡介：

• 在 ASP.NET 應用程式的延展性瓶頸
• 工作階段狀態儲存選項
• 可用的快取拓撲
• 必要的分散式快取功能

內容

其中，問題是否
存在這些問題的原因
答案是什麼？
快取拓撲
不同的選項
Real 世界

ASP.NET，Microsoft，Web 應用程式架構的熱門搜尋會繼續的 leaps 和 bounds 成長，開發人員企業，內和 IT 陣序規範。 沒有但是困難的一部分： 縮放比例現成的 ASP.NET 應用程式是只要不可能的。

延展性會在此內容中有兩個意義。 首先，您必須要能夠有效地處理尖峰使用者載入，因為每個應用程式已通過尖峰和山谷的使用者登入的任何一點的時間數目的方面。 當您設計基礎結構時，您會想要設計應用程式，因此它可以處理，快速和有效地為 nonpeak 載入與尖峰負載。

第二個，您必須要能夠增加系統的總容量。 現在您可能必須只有 5，000 個使用者。 六個月一次道路下, 一年會您可能會具有 10，000 」 或 「 15,000 或 「 在 20，000，且在幾年內您無法得到擁有 100，000 位使用者。 能夠與使用者的數目增加，而 grinding 中止應用程式是哪些延展性是所有關於。 這表示您就可以沒有負面影響效能，任何明顯的方式中新增更多的使用者，或如果有任何降低應該是的可接受的範圍內。

在一或多個 Web 伺服器在 Web 伺服陣列與散佈流量到所有 Web 伺服器的負載平衡器中互相連結上中部署了典型的 ASP.NET 應用程式。 理論上，更多的 Web 伺服器，您將加入更多的要求您應該能夠處理每秒。 架構的 Web 伺服陣列是用來讓 ASP.NET 的延展性。 在理論上 ； 實際上會有點不同。

ASP.NET 應用程式問題，是雖然 Web 技術，提供 Web 伺服陣列的負載平衡器的典雅式架構，資料儲存技術有不保留設定。 當然您可以調整出在 Web 應用程式中新增更多伺服器或藉由增加更多的記憶體和 CPU 能力個別伺服器的強度。

但像的不能夠在相同的比例縮放資料存放區。 它不會縮放，但不是為許多 Web 應用程式層。 因此，任何與資料存放區或資料存取所關聯的您 ASP.NET 應用程式中會是潛在的延展性瓶頸。 多點，資料庫伺服器不會縮放的工作階段或應用程式的資料。

其中，問題是否

讓我們來看看不同 Access 或儲存動作進行工作階段存放區開始，在 ASP.NET 應用程式內。 為每個使用者的要求工作階段是從儲存在開始讀取，並傳回寫入結尾的回應儲存。 在使用者要求開頭，網頁必須執行的需要工作階段資料。 這樣網頁執行時, 可以參考的資料，會載入整個工作階段資料，稱為 「 工作階段物件 」。 頁面將會從工作階段物件讀取部分的資料。 它會將某些更多的資料放入工作階段物件。 這全部會發生在 ASP.NET 處理序和沒有 Trips 所進行的工作階段儲存。

在完成頁面執行，某些會傳回至使用者的需要。 工作階段可能會更新在這段時間，讓目前的工作階段儲存回至儲存區。 它將會保留儲存之前相同的工作階段的下一個使用者要求並且重複相同的程序。

觀點使用者的您按一下連結 ； 使用者會看到來自該連結的頁面時，工作階段有已讀取並工作階段已寫入回至儲存區一次。 因此有一個 ASP.NET 應用程式所做的工作階段儲存區的兩個 Trips。

現在，您做數學。 如果您已有 10，000 個使用者存取所有的頁面，在同一時間，您必須也許是每秒 1，000 個要求。 按一下每個使用者將會 [項目每幾秒內讓每個您必須至少為 1，000 」 和 「 可能更多的要求，將 Web 伺服陣列的第二個。

讓我們假設 Web 伺服陣列] 和 [要在工作階段存放區的兩個存取，Web 伺服器會產生每個要求將 1，000 個或多個要求。 從 Web 觀點來看，這表示工作階段儲存的 2，000 個 Trips。 您可以看到負載可以增加的速度。 這是一個延展性瓶頸可能會發生的地方。

延展性瓶頸可以也發生這種情況而頁面正在執行，並需要讀取或寫入某些應用程式資料。 讓我們使用班機飛行可用性，做為範例。 使用者按一下搜尋飛行從一個位置到另一個，而導致多個頁面上的會讀取 Trips 應用程式資料庫。 然後的不用說，使用者想要讓飛行預定需要某些資料被放入資料庫。 此資料稱為 「 應用程式資料 」 及它儲存在資料庫中 ； 這儲存作業可能會讓多個資料庫來儲存多個資料項目的 Trips。

因此，您無法，的最後風力最多 5、 10、 15，或 20 個的時間超過實際使用者要求的數目的資料庫 Trips 的數目。 因此，在資料庫上的負荷是更，和這可以是個重大的瓶頸。

如果您使用的 SOA (服務導向架構) 環境，且您的應用程式進行到另一個可能是您的資料中心內或在不同的資料中心的服務圖層的呼叫，第三個延展性瓶頸是有關。

伺服器的階層架構通常牽涉到伺服器陣列，因此可擴充的 Web 應用程式架構的方式相同。 但服務層會有相同的延展性瓶頸之應用程式，因為它依賴它自己的資料庫。

因此應用程式其他服務有相依性，又有延展性的瓶頸其資料庫上有相依性，而鏈結是只為強式，為其最弱的連結]。 如果服務因為的記憶體的資料庫不會縮放，無法調整您的應用程式 (請參閱 [圖 1 )。

[圖 1 ： 資料庫會成為瓶頸，隨著 Web 伺服陣列增加

不論實際資料庫是否在大型主機或關聯式資料庫。 資料存放區的資料存取只就無法縮放，而且它無法跟上 Web 技術的延展性。 並在資料儲存區中的，這些瓶頸防止縮放比例的 ASP.NET 應用程式。

存在這些問題的原因

為什麼無法調整資料存放區？ 讓我們先處理 Microsoft 所提供的三個工作階段狀態儲存選項： InProc，StateServer，和 SqlServer。 InProc 會有限制。 它設計用於在單一伺服器]、 [單一處理程序環境中，，它不會無法運作在多重伺服器或 multi-process ASP.NET 環境中。 不保留工作階段。

以下是會發生事。 如果要在一部伺服器上, 啟動的使用者，並有建立工作階段。 如果負載平衡器然後傳送到不同的伺服器的使用者，應用程式找不到該工作階段，它會認為使用者是全新的開始，並且會問她再登入一次。 每次使用者按一下任何項目上，她就必須登入，所以她將無法繼續執行。 應用程式將無法運作。

您也可以解決這的一個方法是使用 「 自黏工作階段 」 的功能，可讓您永遠都讓應用程式會在伺服器上尋找該工作階段使用者要求回相同的伺服器的路由。

您也可以藉由無法在伺服器上建立 Web 處理序區中處理 InProc 限制。 Web 處理序區時，應用程式有多個相同的伺服器上執行的 ASP.NET 背景工作處理序。 如果避免使用 Web 處理序區則還有只有一個處理序，並，至少會允許在 Web 伺服陣列中使用 InProc。

這些兩種因應措施不過是來自理想。 自黏工作階段造成重大的延展性瓶頸，因為某些伺服器負載增加超過其他因為使用者工作階段的長度不是統一。 某些使用者登入只有一分鐘，其他 20 分鐘。 某些伺服器就會收到大量的工作階段，但幾乎空白或可用或閒置，這些都是]。 如果即使加入更多方塊，您會不一定要改善輸送量。

此外，InProc 會有記憶體的限制。 在您的 ASP.NET 處理序的每個工作階段需要的記憶體。 您要增加的工作階段數目，您的背景工作處理序的記憶體需求大幅增加。 32 位元的平台上的不過，沒有背景工作處理序，1 GB 記憶體限制，而且的問題。 您無法成長，超過 1 GB 背景工作處理序記憶體，連同其他資料和應用程式的程式碼哪些符合的工作階段資料。 因此 InProc 會造成瓶頸。 您有更多使用者，您會遇到這些問題的更多。

StateServer 則會將工作階段狀態儲存在從 ASP.NET 背景工作處理序，不同處理序中，但它太會有限制。 您可以設定它，讓每個 Web 伺服器都包含它自己的 StateServer，或您可以指定一個不同的方塊，並完全中該方塊維護狀態。

使用第一個選項，問題會是您仍然必須使用自黏工作階段。 建立工作階段的位置的位置永遠都必須返回到它。 此第一個選項只會降低 InProc Web 處理序區限制。 它不會解決自黏工作階段的問題，可以讓您額外的方塊，其他人已經堵塞，即使不取得使用。 最終結果給使用者會是工作階段和回應時間變得非常緩慢。

如果任何 Web 伺服器往 [StateServer 下上的 Web 伺服器] 方塊也當機，您會失去所有的工作階段，因此，此組態選項，其他缺點是。 true，您不會遺失在網站上，所有工作階段，但您執行遺失儲存在該方塊，任何工作階段並可接受。 在理想的情況下，不要遺失任何工作階段。

如果您選擇其他的組態 StateServer 提供 — 一個專用的 StateServer 方塊 — 您不再需要使用自黏工作階段，因為每個 Web 伺服器會移至同一個專用的方塊。 但您現在有更大的問題： 如果該方塊當機曾經，整個 Web 伺服陣列是往下因為每個 Web 伺服器正在嘗試從該方塊中取得其工作階段。

那不是全部。 加入更多的 Web 伺服器以及每秒交易擴大，取得淹沒這個專用的 StateServer 方塊。 因此，它會快速地變成延展性瓶頸。 因此延展性問題無法解決使用 StateServer，不是使用其中一個組態。

現在我們來將工作階段狀態儲存在 SQL Server 資料庫的 SqlServer，並可以視為專用的 StateServer。 這是 Microsoft 的首要資料庫伺服器針對高交易環境而設計。 這是更比為 StateServer 具延展性的因為您可以建立資料庫伺服器的叢集。

在 SqlServer 的組態所有 Web 伺服器實際上會都連接到專用的 SqlServer 方塊，儲存所有工作階段。 很像是每一個 Web 伺服器連線到一個專用的 StateServer 方塊。 這背後的概念是 SqlServer 會比在 StateServer，更可縮放。 但 SqlServer 不為狀態的伺服器的速度，因為在 StateServer 是的記憶體中資料存放區的而且因此，有可接受的效能。 另一方面，SqlServer 不是 X 的記憶體中資料存放區。 它會是一個磁碟架構資料存放區。 所有的資料庫會存放在磁碟上，因為增加很大的記憶體不足，無法儲存整個資料庫。 因此，資料庫儲存資料的是磁碟的永續性儲存裝置上。 由於磁碟儲存裝置，SqlServer 效能並不是速度，導致效能置放。

SqlServer 可以有多個組態。 在獨立設定是最常見的中,，沒有所有 Web 伺服器都與，只有一個資料庫伺服器，並且增加 Web 伺服陣列的大小，並新增更多的 Web 伺服器，您將多資料庫負載 (請參閱 [圖 2 )。

[圖 2] ASP.NET 工作階段仍，一個瓶頸和資料庫也不會 fullyscalable

加上，您必須在效能問題的因為 SqlServer 不是會根據記憶體，並在您有延展性問題，因為它不可以擴充為大部分。 您可以調整設定藉由加入該方塊的 CPU，讓硬體功能更強大，但您無法將新增更多的資料庫伺服器方塊，您會增加 Web 伺服陣列。 您可以可能繼續從一到兩個或兩到三伺服器，因此 SqlServer 會提供資料庫叢集是個以上的資料的 StateServer 不會縮放的功能，但是它也會具有其限制。

其他問題 SqlServer 儲存已是所有的工作階段放在單一資料表中。 一旦您調整設定，並行存取 」 及 「 工作階段資料的同時更新，鎖定爭用會變成明顯。 因為您的每秒多交易您需要多鎖定的延遲，因為所有保留在一個資料表。

所以，SqlServer 縮放多個伺服器狀態時, 它交給您的效能問題，並沒有充分縮放。 此外，它不會縮放直線。 您應該要能夠增加 Web 伺服陣列從一個 「 5-50 到 100-伺服器伺服陣列，和 Web 伺服陣列本身應該很順利地成長，但是，資料存取不會增大相應。 如我先前所述，資料庫將工作階段儲存在資料庫，不讓任何主要的改進，因此是其中一個不會增大，這些資料儲存區存取。 在狀態伺服器環境的只有遞增的改進。 此外，在 SqlServer 會成為瓶頸的資料應用程式以及工作階段資料。 因此，資料庫伺服器不會工作階段或應用程式資料的縮放。

答案是什麼？

這樣可以非常快速，速度為 StateServer，解決方案是記憶體中儲存機制。 不過，它應該是幾乎線性調整。 線性的延展性，表示當您新增更多伺服器，您會幾乎相乘容量。 例如，如果您無法處理的每一個方塊的秒的 10，000 個交易，新增第二個方塊應該給予您接近第二個總計每 20，000 的交易。 請注意幾乎線性並不完全 20，000 — 可能是 19,000，； 它不會，但是，是 12,000] 或 [15,000。 而這是我們的需要： 幾乎線性，可擴充的儲存體，而且也應該在記憶體中。

因為的這些兩個的需求我們不談持續性儲存體有其他的需求，並供長期。 雖然記憶體中儲存永遠是暫時性和暫存資料庫被供長期儲存區。 但我們需要暫存檔。 我們只需要在使用者工作階段 (或) 可能是這個暫時儲存區中的資料儲存的應用程式到幾天或可能在幾週在大部分的幾個小時的持續時間。 然後該資料可以消失因為一定永久主要儲存區，是，我們可以重新載入資料從資料庫。

因此這記住的所有，我們可以把資料儲存機制，稱為快取 「 分散式的區，」 概念，已經成為受歡迎，因為它提供上述，所引用的優點為 [圖 3] 顯示。

[圖 3 relieving 壓力，在資料庫伺服器上的分散式快取

因此很快速，並將它設計為相當直線，散發成長如果您有正確的通訊機制 (也稱為快取的拓撲) 時，特別是，在的分散式快取會是 In-Memory。

分散式快取區必須提供高效能] 和 [線性的延展性，而且因為它存在記憶體中，它必須提供複寫，因此，如果任何電腦當機 (該電腦中的記憶體變成可用的)，另一台電腦將會有資料，且您不會遺失任何。 複寫提供多個備份的相同的資料在不同的位置不同的方塊以及所做的您會達到 100 %，您的資料儲存區的期間的時間。

分散式的快取會儲存在.NET 物件或 Java 物件，或重要的任何其他的資料會像 XML 文件。 它在以在準備好的格式儲存資料。 它並沒有的資料表和資料列和主索引鍵和外部索引鍵資料庫的概念。 在程式設計人員，分散式的快取是資料本質上雜湊表，其中有是金鑰每個索引鍵值，和的值的物件。 您需要知道在的金鑰，而且根據索引鍵，您可以擷取所要的物件。 這是一個邏輯可以跨越多個伺服器的快取。 您也可以加入伺服器在同一時間增加快取叢集大小，而您也可以在同一時間來壓縮快取叢集，而不需停止任何移除方塊]。

快取拓撲

不同的拓撲的有效的快取應該提供的複寫，分割，在複寫和分割的混合式和用戶端或本機快取。 其概念是使用的有不同的快取拓撲不同類型，進行非常有彈性的快取。 複寫拓撲複寫的快取的次數，您需要 (請參閱 [圖 4 ) 如何根據多次]。 其目的您具有讀取大量的快取使用量中，但是無法大量更新的情況。

[圖 4 ： 複寫的快取很適合使用讀取大量的使用方式

高度的可調整拓撲的更新需要大量或交易式需要快取的資料分割的快取。 這可能是 ASP.NET 工作階段資料是非常的異動。 如前所述，為每個網頁的要求工作階段就會讀取一次，並一次，更新，因此它具有讀取和寫入的相同數目。

分割的拓撲 (請參閱 [圖 5 ) 是絕佳的更新必須完成的次數，至少為您正在進行讀取的環境或相當接近的。 在這個拓撲，以快取。 當您新增更多] 和 [更多的快取伺服器，快取進一步分割方式，幾乎一第 n 個 (N 表示節點的數目) 的快取會儲存在每個快取伺服器上。

[圖 5 A 分割的快取很適合使用寫入大量使用 。

第三個的拓撲，是分割和複寫版本的混合。 您可以分割快取，並，可以在同一時間，會複寫每個磁碟分割。 因此，您會得到最好的兩個世界。 您可以分割和成長，加上您可以複寫的可用性，以確定沒有資料遺失 (請參閱 [圖 6 )。

[圖 6 磁碟分割的複本的快取很適合使用寫入 intensiveusage 與可靠性 。

分割和資料分割的複寫混合拓撲的協助，您可以增加直線的延展性快取。

在用戶端] 或 [本機快取則是位於應用程式伺服器上的第四個非常有用拓撲。 這種類型的快取非常接近應用程式，而且甚至可以 InProc。 它會通常是實際的大型分散式快取的小型子集，並以在任何時間在該應用程式已經被要求為基礎。 任何在應用程式要求將會保留在用戶端快取中。 下一次應用程式希望相同的資料就可以自動找出它在用戶端快取中。 它不需要移至分散式的快取，以儲存，即使與資料的存取，因為分散式快取通常是在網路上不同的快取伺服器或叢集的快取伺服器上。 用戶端快取可讓您的其他效能及延展性的提升。

用戶端快取中的資料必須保持與分散式快取同步處理。 如果相同的資料已變更，在分散式快取中，分散式快取必須與用戶端快取中同步處理的變更。 這是一個重要方面，您不希望自己能夠只是是完全中斷連線在本機快取。 這是僅是無法接受的因為您有資料完整性問題的 InProc 快取的對等用法。 您有多個的副本，相同的資料，以取得非同步。

不同的選項

有可用的多個分散式的快取功能... 為在大多數的情況下可用的解決方案提供一組更有限的功能雖然商業印刷的會提供更多的選項和功能。

除了從高效能、 延展性，高可用性，有效率的分散式快取都必須包含幾種金鑰的功能，來協助您讓快取重新與主要資料來源同步處理，是否在資料庫或大型主機。 快取應該有一個到期日選項，讓您可以分辨它來執行自動到期日可能是一個絕對時間或內容的呼叫滑動時間。 基本上的閒置時間 ； 如果沒有使用資料，它已自動過期。

快取應該也能夠管理不同的型別的資料之間的關係。 關聯式大部分的資料。 例如，如果您有客戶，您有該客戶的訂單是一個客戶資料 」 和 「 訂單資料之間的關係。 如果您快取客戶和訂單資料，而您不小心從快取刪除客戶資料，合理的順序會自動刪除。 這個的執行個體中，您不知道是否您從快取中移除客戶資料] 或 [永久刪除。 萬一您永久刪除它，順序是也無效現在因為順序必須是有效的客戶。

有其他類似的類型，必須在快取中管理的關聯性。 如果快取不執行它，然後應用程式有保持追蹤] 和 [，是很麻煩。 被呼叫在 「 快取相依性概念 」 的一個 Microsoft 快取物件，在 ASP.NET 非常有用，。 一個快取的項目，取決於另一個。 如果其他的快取的項目是從快取中曾經移除，或甚至更新，以及移除第一個快取項目。 這是一個功能強大的快取的相依性概念，應該會在關聯式資料的快取的所有快取。

與資料庫同步處理，是另一個重要的功能，快取。 通常是由多個應用程式共用資料庫。 如果使用快取的應用程式只有一個更新資料庫，您可能毋須資料庫的同步處理功能。 但經常，其他的應用程式有時候協力廠商的應用程式的更新資料庫中的資料，因為資料庫共用、 一般存放區，而且這些應用程式未使用您的快取。 它們可能甚至無法.NET 應用程式。 它們可能是協力廠商應用程式沒有控制項，但它們會更新它在資料庫中。 因此您必須允許的情況，資料庫可能會更新您的應用程式之外，但部分，已在資料庫中更新的資料也會快取。 因此，快取必須要能夠同步處理。 它有能夠知道時有的資料是不再相同資料庫中。 它必須從快取中移除該資料，並在可能甚至重新載入最新的副本，從資料庫。 透過由資料庫伺服器或輪詢資料庫快取所引發的事件，可以完成資料庫同步處理。 事件均為課程更即時的且輪詢有些許延遲。 但輪詢會更有效率，如果在變更大量資料。

事件通知是之間最重要功能應使用有效的分散式快取中。 快取通常被共用的多個應用程式之間] 和 [甚至內多個使用者之間的應用程式。 因此，快取在萬一，例如，更新或移除快取的物件，應該具有的事件通知 」 機制。 如果您的應用程式使用相同的資料，您可以從資料庫或一個新的拷貝，從快取本身可能是您可以重新載入，所以會收到通知。 通知機制改善多位使用者或多個應用程式，透過快取之間的共同作業。

Real 世界

IT 管理面臨與資料庫，相關聯的所有效能問題並在瓶頸的情況下如果您夠幸運，能夠報告給開發人員，它們可能會嘗試加以解決。 不幸的是，開發並非永遠內部。 通常您正在使用住，並管理協力廠商的應用程式。

無論如何，最好的地方開始實作分散快取來開啟瓶頸] 及 [Turbo 免費您的應用程式是 ASP.NET 工作階段存放區，因為您不需要開發人員而定。 沒有程式設計的相關。 簡單快的記憶體中分散式取取代現有的工作階段儲存。 此外，實作 ASP.NET 工作階段存放區在分散式快取提供有機會看到 accrue 的效能及延展性，使用的優點，而且接著您可以決定要執行應用程式資料的相同。

若要遇到延展性改善，您可能必須執行分散式快取存放在實際執行，或者必須模擬的負載，在您的測試環境。 您可能必須存取可協助您在模擬大量負載之前放在實際執行的分散式的快取的測試環境中執行壓力測試的問答。 大部分的 IT 管理員將可能不會是負載的舒適放在分散式的快取生產除非他們必須測試它第一次他們的品質保證環境即使它們無法模擬量相同。 因此，這是一個很好的開始。

一次您啟動並執行分散式的快取，而且 reaping 其優點，您可以共用您新 ASP.NET 工作階段效能和延展性結果與您的公司內部的或協力廠商廠商的開發小組。 您可以使用手中硬碟的辨識項，要求開發小組，分析的區域，它們可以快取應用程式資料，以及此分散式快取中。

快取應用程式資料會提供進一步的提升，並在許多情況下有許多更提升比只使用分散式的快取，ASP.NET 工作階段儲存區。 開發人員能夠辨識更頻繁地更新它們比讀取的所有資料項目。 即使在交易式資料 (： 客戶、 訂單，類似) 是不錯的候選快取，即使它會保留在快取之前過期的幾分鐘。 這是因為重新這個簡短時間內，資料可能會讀取許多次，並如果這個重新時，是從快取，而且無法從資料庫，它讓讀取載入大量的資料庫。

但是，快取應用程式資料的開發人員，它們就必須執行的程式設計分散式快取 API 呼叫。 這個構想是非常簡單。 他們的應用程式會嘗試從資料庫擷取資料時, 必須先檢查快取。 快取是否資料則會將資料取自快取。 否則，應用程式從資料庫擷取資料，快取它，並為它提供給使用者。 這的種方式資料將會找到在快取中讀取的下一次。 同樣地時在資料庫中修改資料，, 它應該也更新快取中。 而且，如果在多部伺服器上存在的快取，它必須因此可以同步自動以確保如果應用程式是在 Web 伺服陣列中執行的相同的快取資料從伺服陣列中的所有伺服器存取。 如需主題的詳細資訊如何開發應用程式使用分散式的快取較佳的延展性的尋找中 7 月的 MSDN Magazine 我即將文章。

Iqbal Khan 是總裁和技術 Evangelist 的 Alachisoft，公司，提供 NCache — 業界的前置的分散式的.NET 快取提高效能及企業應用程式的延展性。 Iqbal 印第安那大學，Bloomington，從電腦科學中收到的 MS，於 1990 年。 您可以將他在到達 iqbal@alachisoft.com.