爲什麼ASP如此頻繁地編譯我的視圖？

Question

我們有4臺服務器進行負載平衡：

• 4核2.6GHz的@（E5-2650 V2）
• 14GB RAM
• 的Windows 2012 R2
• 高性能功率設置
• IIS 8.5
• ASP 5.3
• EF 6.1

它們每個都有一個應用程序池，只有一個工作進程和一個網站。每個服務器都有自己的本地副本（DLLs &視圖），在本地磁盤上運行。我們使用IIS虛擬目錄指向羣集文件服務器上的共享日誌文件和常見映像等（僅限內容）。應用程序池設置爲在閒置時不關閉（間隔爲0），並且我們也禁用了每1740分鐘的重複週期時間間隔。

我們在所有服務器上都安裝了New Relic的.NET代理，並且通過慢速事務日誌查看，我可以看到許多請求需要15秒左右才能完成。仔細觀察，我可以看到System.Web.Compilation.AssemblyBuilder.Compile()和System.Web.Compilation.BuildManager.CompileWebFile()的共同呼叫。

據我所知或理解，ASP會在第一次請求它們時編譯這些視圖，並將其緩存（對C：\ Windows \ Microsoft.Net中的臨時ASP文件），然後從那裏加載後續請求。

我很困惑這是怎麼發生的 - 當我訪問這些URL時，TTFB大約是400ms，並且由於持續的負載，我看不到網站「丟失」它們的緩存並需要編譯視圖再次。這些網頁經常被打 - 這是一個電子商務商店，我可以看到它經常發生，並在我們最受歡迎的網頁上：目錄（類別/品牌/性別等）列表和產品詳細信息。

我已經設置了針對每個應用程序池的設置，以便在回收時記錄事件，並且在檢查事件查看器中的WAS服務時沒有記錄任何事件。我們還安裝了New Relic服務器，查看過去6個小時的數據，我發現任何服務器的RAM使用率都沒有下降 - 這將表明應用程序池回收。這讓我很困惑！

我正在考慮將我們的視圖作爲我們發佈過程的一部分進行預編譯 - 它確實很有意義。但感覺就像是在解決問題，或者掩蓋一個我認爲不應該發生的問題。我們在發佈模式下構建我們的網站，並在所有web.config文件上擁有<compilation debug="false" />。

任何人都可以想到這個的任何原因？

Answer 1

這是因爲JIT（Just-In-Time）編譯工作原理。

當您構建應用程序時，它將轉換爲.NET Microsoft中間語言（MSIL）或中間語言（IL）。

當您的應用程序被訪問時，公共語言運行時（CLR）只將代碼的執行的IL部分轉換爲本地指令。

實時編譯過程將IL轉換爲本地機器指令，它是CLR的一部分。

簡而言之，當您運行.NET應用程序並且您的程序調用方法時。 JIT編譯器從元數據中讀取IL並將其編譯爲本地指令並運行。接下來當你的程序調用相同的方法時，CLR直接執行本地CPU指令。此過程爲第一個方法調用增加了一些開銷。您可以選擇使用NGEN預編譯應用程序的其他選項，通常不建議這樣做，因爲您將忽略一些由於其對底層硬件平臺的瞭解而只能由JIT執行的優化。這兩篇文章進行了詳細介紹 http://geekswithblogs.net/ilich/archive/2013/07/09/.net-compilation-part-1.-just-in-time-compiler.aspx和https://msdn.microsoft.com/en-us/library/ms366723.aspx

還有其他的東西，你可以嘗試，可以幫助你加快你的應用程序。您可以使用IIS應用程序預熱模塊How to warm up an ASP.NET MVC application on IIS 7.5?，實施分佈式緩存等來緩解您的某些應用程序瓶頸。