Internet Information Services: Scaling ASP.NET Applications: Lessons Learned

發行項
08/18/2016

網際網路資訊服務

調整 ASP.NET 應用程式：心得

Richard Campbell

綜覽：

開發人員/IT 共同作業的重要性
了解主體調整策略
在小組間分享知識
在核心知識組上達成共識

事實很簡單，沒有任何應用程式第一次調整就成功的 — 要一切剛開始就恰到好處是不可能的。若要成功調整應用程序，您不但必須了解應用程式是怎麼建置而成的，還必須知道它執行的作業環境是如何運作的。換句話說，您需要開發同仁和網路同仁兩方提供資訊。缺少知識交流，就無法成功。

調整的基礎

在深入探討之前，讓我們先談談實際調整 ASP.NET 應用程式的必備條件。一般採納的基本策略有兩種 — 專門化和分散化 — 而大多數大型調整的 ASP.NET 應用程式兩種都適用。另外，書中幫助您進行 ASP.NET 應用程式調整的竅門都不出這兩者。

專門化需要分隔應用程式的元素，以利獨立進行調整。比方說，您可能建置專用的映像伺服器，而不是使用相同伺服器來轉譯 ASP.NET 網頁。映像伺服器的最佳設定與 ASP.NET 伺服器大不相同。另外，將映像要求與應用程式其餘部分相區隔，也開啟了使用協力廠商資源來提供映象服務的可能性。相同的方法也適用於其他資源檔案。

另一方面，分散化則牽涉到把應用程式對稱地散置在多部伺服器間，一般稱為 Web 伺服陣列。ASP.NET 應用程式特別適合分散化，因為每個個別的頁面要求都相當的小，而且特定使用者的互動大多不受其他使用者影響。分散化可謂是「向外延展」原理的化身，當中是由多部中級效能伺服器合作來服務使用者，而不是像「升級延展」策略，是由一部大規模的伺服器包辦。

結合專門化和分散化可提高效率 — 您可以只分散需要額外效能的應用程式元素。例如，如果您已建立專門化映像伺服器，但是提供的映像不足，與其為整個應用程式新增伺服器，您可以直接新增映像伺服器。在您埋頭於提升 ASP.NET 應用程式的效能和延展性時，請務必將這些策略謹記在心。

達成共識

開發人員與網路/IT 人員可能會在每個 ASP.NET 應用程式的生命週期中的某段時期碰面。運氣好的話，他們會在應用程式部署之前碰面，但有時候這只發生在大難臨頭的時候 — 譬如，當應用程式在測試環境下執行順暢，然後發行給使用者，卻慢如老牛拉車 (此時正是像我一樣的顧問現身的時候)。

當開發人員與網路人員會面時，主要的目的是交換資訊。開發人員握有關於應用程式的重要知識，而網路人員則持有作業環境的資訊。每個群組都必須了解另一個群組的資料，而且他們在應用程式生命週期內越早碰面越好。

第一次會面不應該在發生危機時才進行。兩個團隊之間若沒有基本的了解，要找出應用程式的執行為何未達要求將非常的困難。此外，也可能為了自衛而輕易判定問題完全出在另一個小組身上。而且那樣的斷論向來不實 — 要解決任何複雜的問題必定需要雙方的合作。

然而，即使是在相安無事的時刻，這類的會面也可能充滿挑戰。我主持過的那些會議一般是網路同仁坐在會議桌的一邊，開發同仁則坐在另一邊。接著是兩邊彼此乾瞪眼。為了打開話匣子，我簡述了會議的目標，特別強調交換知識。由誰開頭並不重要，我打算從網路小組應知的開發資訊下手。

網路小組須知的開發資訊

每個 ASP.NET 應用程式都有自己的怪癖，但每種案例中都有通用的主要元素。而 web.config 檔案就是其中之一 (見 [圖 1])。Web.config 是開發和網路之間的交叉點。有時候它是由開發人員設定，有時候是由網路同仁設定。無論由誰設定，web.config 的內容都會限制硬體和網路設定，並且直接影響應用程式的運作方式。若要詳細探索 web.config 檔案的每個小細節，很容易就會佔滿整本書的篇幅，這裡的重點是，雙方各組必須研究 web.config 檔案，並對設定所代表的意義，以及各種設定對應用程式還有環境有何衝擊等方面達成共識。

[圖 1] 顯示一些應用程式設定和自訂錯誤設定的基本 web.config (按一下以放大影像)

譬如，web.config 的 <authorization> 區段指出在應用程式中要如何驗證使用者，進而定義相依性。如果應用程式使用 Windows® 驗證，可能得仰賴 Active Directory®。如果是使用表單式驗證，那麼使用者帳戶的資料存放區上就存在相依性。這肯定值得一談。

<customErrors> 區段也值得注意，因為它會影響失敗情況呈現給使用者的方式。這不是複雜的設定，但是值得討論，藉此來了解會碰到什麼錯誤頁面。在合作的早期，可能沒有自訂的錯誤頁面 — 這也值得好好談一下。

web.config 的 <appSettings> 區段可能特別重要。這通常是開發人員藏匿全域值的地方，像是資料庫的連接字串。這不僅是相依性的絕佳來源，也是為容錯移轉、移轉等作規劃的重要一部分。但由於 <appSettings> 區段是完全自訂的，因此內容雜陳，而且可能需要許多解釋來了解當中的內容。遺棄的項目往往是被放在這個區段 — 也就是應用程式中沒有什麼用處的值。

即使開發人員沒有使用 <appSettings>，網路/作業同仁可能會希望他們使用 — 將所有資料庫連接字串都放在該處，是建立簡單容錯移轉策略的有效方法。如果資料庫伺服器故障了，便可插入替代字串以指向不同的資料庫伺服器。在開發週期早期抓住此良機，可提高應用程式的可靠性和易管理性。

最後，從調整的觀點來看，您在 web.config 中應該注意的一個絕對重要的值，就是 <sessionState> 標記，這個標記可決定存放應用程式的工作階段資料的地方。根據預設，工作階段資料是存放在「InProc」，或是 ASP.NET 應用程式的處理序空間內。如果工作階段資料是設定用於同處理序，表示所有負載平衡都必須「連在一起」 — 必須始終將指定使用者送回工作階段所在的相同伺服器。這在開發人員和網路同仁之間可說是很重大的會談，因為它會對您要如何調整以及如何容錯移轉產生直接的影響。對此及早進行討論可在試圖偵錯應用程式時，省下不少的麻煩。

會談一談到工作階段狀態，話題就很容易轉到應用程式的一般負載平衡需求。有些環境具有專用的負載平衡硬體，而且有特定的功能 — 但要是應用程式無法處理這些功能，也無用武之地。我就碰過硬體負載平衡被用在具有同處理序工作階段資料的 ASP.NET 應用程式的情況。產生的後果是工作階段偶爾會無緣無故的消失。看起來像是應用程式的錯誤，但不然 — 這其實是設定有誤的關係。

網路同仁必須清楚地從開發小組確知到底什麼樣的負載平衡配置才適合應用程式。這基本上是雙向溝通，除了需要知道有什麼負載平衡配置可用外，還得了解應用程式可以容錯的程度。在應用程式的生命週期早期進行此溝通，有相當的優勢，因為這樣一來，您便可以事先規劃改採跨處理序、非相似性的負載平衡配置。

等到 ASP.NET 應用程式準備好進行部署 (或是已處於初始的部署階段)，開發人員將可對應用程式速度快和速度慢的區域一清二楚。最重要的是，他們將能判斷系統內的瓶頸或潛在的危機點。如果網路/作業小組知道這些瓶頸的話，便能事先針對問題作好準備，甚至防範未然。

例如，我就曾處理過一個應用程式每晚在應用程式停頓的時候有個龐大的資料負載處理序。開發人員於是建置了資料負載機制，進行測試，並了解它的運作方式。他們知道這對資料庫來說負擔很沉重，但卻是有效解決問題的好方法。

但是他們從未告訴網路小組這個處理序的存在，也沒提他們把它排在凌晨 1 點執行 — 剛好是資料庫備份執行的時間。資料庫繼續保持線上狀態，但它在備份時的執行速度慢很多，因為送到資料庫的所有交易都扣留在交易記錄中。

衝突一直等到同時執行的資料負載和備份導致資料庫交易記錄量用盡了磁碟空間才被發現。將資料負載移到凌晨 3 點再開始，便徹底解決了問題 — 但是在危機發生後的幾天才解決。

及早針對應用程式中這類工作負載項目進行討論，可為將來省下不少麻煩。

開發小組須知的網路資訊

當會談進行到網路同仁向開發同仁解釋他們的國度時，我最喜歡從網路圖開始談起。開發人員眼裡的網路往往像 [圖 2] 一樣 — 也就是沒有網路，只有網頁伺服器、瀏覽器和網際網路。

[圖 2] 開發人員眼中簡單的網路 (按一下以放大影像)

不用說，真實的世界要複雜許多。雖然已經過簡化，但 [圖 3] 還是比較接近事實。看一下 [圖 3]，您馬上會滿腹疑問，例如「虛擬私人網路 (VPN) 使用者要如何使用應用程式？」或是「內部使用者與公用使用者之間進行驗證有何差別？」等。

[圖 3] 開發人員必須了解的真正網路 (按一下以放大影像)

光提供網路圖很顯然是不夠的。詳細解釋網路也很重要，因為光看圖表是不可能知道到底有哪些元素會影響應用程式。您必須一一解說公用使用者、VPN 使用者和內部使用者的實際連線程序。而討論現存的各種防火牆規則，尤其是在更複雜的 DMZ 式網路架構中，將自然而然地帶出應用程式的潛在問題。

在應用程式部署之前，甚或是在開發程序開始之前進行所有這些討論顯然是有利的 — 但無論如何，討論終究需要進行，而且關鍵在於讓會議桌邊的每個人都了解整個網路圖。

網路也是容錯移轉和備援模型的競技場，但若沒有一些軟體支援，或對行為有最基本的認識，這些模型很難如預期運作。因此，詳細討論各種不同的失敗案例的情況是不可少的。如果資料庫上設有叢集，這將影響與存取資料庫相關的程式碼。例如，查詢可以在伺服器轉換後重試嗎？如果有可用的備援網站，資料要怎麼複寫到該網站呢？網站之間要如何進行轉換呢？

再次強調，及早進行會談是有幫助，但遲做總比不做好 — 所有參與應用程式的相關同仁都必須對這些事情是怎麼運作的有所了解。沒有什麼比備有容錯移轉方案，卻在需要的時候不能用更令人挫折的了。

最後，還有另外一項重要的網路資源需要分享 — 實際執行記錄。我總是建議將實際執行記錄提供給開發小組。網路同仁對於這項要求的反應通常是「只要開口，我就會寄給你」。我覺得這樣是不夠的 — 讓開發人員能夠自行擷取記錄檔 (通常是從備份網站) 會更有效。

在發生危機時，實際執行記錄是不可少的。要了解實際上發生什麼事，實際執行記錄往往是有經驗的真實資料的最佳 (而且是唯一) 來源。但是它們在更普通的情況下也一樣重要。當開發人員可例行存取實際執行記錄時，他們便能逐一檢查來觀察新功能的行為。而這是找出您的功能未如預期運作，並在它造成危機之前加以修正的絕佳辦法。如果每個人都可以存取記錄檔，您就能更快對問題作出回應，修正的速度也會更快。

回到調整

網路與開發小組之間的會面重點，在於了解調整 ASP.NET 應用程式相關的完整問題範圍。應用程式操作的實際環境會直接影響應用程式執行的程式碼的運作方式。所有與調整相關的策略都將左右它在環境內的行為。採用專門化策略，例如區隔應用程式的 SSL 相關部分，可能需要變更網路環境，也可能對伺服器本身進行變更。

即使很明顯是以程式碼為主的變更，像是使用快取，也會對環境產生影響。這是因為當您將資料快取新增到 ASP.NET 應用程式時，等於是減少資料庫呼叫的數目來交換更高的記憶體使用量。最後，您可能增加了您所需的 ASP.NET 伺服器數量，或增加了伺服器上工作者執行緒的再利用數目，因而在網路監視端引發了事件。

調整 ASP.NET 應用程式確實會影響開發與網路雙方的人員 — 因此邀請兩批人馬投入決策過程是值得的。共同作業往往會產生小組在獨立作業時察覺不到的全新解決方案。比方說，網路同仁可能知道公司內有現成的硬體方案可幫助開發人員達成效能和調整需求。深入談論應用程式和環境的細節將可揭開這些機會。

合作交火戰

調整 ASP.NET 應用程式的資源

調整時發生危機不見得就是壞事 — 事實上，這通常是件好事，畢竟這也是因為有太多使用者想要執行您的應用程式才發生的，無疑證明了應用程式的價值！不過，現在您必須解決危機。

有時候調整危機是因其他事件引起的 — 或許是貴公司正在舉辦宣傳活動，或是有部落格文章報導您，或是社群網站一次將人數龐大的網友指向您的網站。突然間，您身陷重圍，努力讓應用程式順利執行。跟您猜得一樣，最好是在這種情況真正發生前先演練一下。而示範共同作業如何協助組織在這類的危機中存活下來，是讓開發人員和網路同仁會議落幕的最佳方式。

管理危機的首要問題是：「我們要怎麼偵測出網站已經超載？」答案往往是：「我們接到 CTO 的電話。」如果網站出問題的第一個症狀是外部的人來電告知，那麼您麻煩可大了。有些適當的計量功能應該可以在電話響起前告知您發生了問題。它當然無法制止電話響起，不過至少可以讓您預先準備要怎麼回答。回答 CTO「喔，真的嗎？」對您的前途並沒有什麼幫助。

下一個問題 — 電話應該先由誰接聽？由誰對事件作出回應？網路人員通常會先接到警告，但該人員可能缺乏相關經驗，因此應該要有清楚的升級計畫。接下來該收到通知的是誰？挑戰在於進行初期迅速的診斷，以找出所面臨的是哪種問題。網路中斷是一回事，調整問題又另當別論。關於調整問題，最好邀請開發小組儘早參與。

參與交火戰的每個人都需要有充足的資訊，因此有效的存取權限是關鍵。目標是要盡可能多傳播資訊，以利有效的診斷，而且這最終應該指明解決方案的範圍。

如果唯一的解決方法是編寫程式碼，事件往往在程式碼編寫好前就已結束。為了建立未來的開發優先順序，小心觀察事件是理所當然的，但是試著寫一長串程式碼，並且不仔細測試就在生產環境下執行，可謂不智之舉。交火戰的首則 — 不要火上加油。

碰到調整問題，有時候耐心等候才是解決之道。但這也是您要作的決策。

同時，針對這些偶發事件作規劃，意謂著可迅速採取不同的因應措施。結合網路和開發資源來因應調整問題，通常可及時加以解決，成效之快或許還可讓宣傳活動的成效更加彰顯。

總括來說，從網路一方獲得的心得是，高度調整、有效執行的 ASP.NET 應用程式，代表建置應用程式的同仁與部署和操作它的人之間共同作業有成。

共同作業是不可避免的，因此各組之間最好及早會面來分享資訊。會面的目的是要對應用程式的元素、作用、運作方式、仰賴的基礎、負載下的行為模式，以及應用程式如何應付不時產生的問題有所了解和達成共識。

這類的共同作業除了成效驚人外，還能使公司更加靈活，不僅可以更迅速地回應問題，還能針對應用程式的需要溝通明確的目標，以便在未來順利執行。

Richard Campbell 身兼 Microsoft 地區主管與 ASP.NET 的 MVP，他同時也是《.NET Rocks》的主持人之一，這是以 .NET 開發人員為主的網際網路廣播脫口秀 (請前往 dotnetrocks.com)。他花了好幾年的時間與公司合作磋商 ASP.NET 的效能和調整作業，他也是 Strangeloop Networks 的創辦人之一。

共用方式為

目錄

其他資源