MVC 4應用程序渲染時間與Visual Studio 2012

當我在Chrome上使用Visual Studio 2012運行我的mvc應用程序時，我的頁面需要36s渲染 - 使用mini-profiler看到了這一點。當我將該項目託管在遠程服務器上並點擊該頁面的服務器時，第一次命中需要36秒。但在後續命中時，它會顯着減少到1秒或更少。任何想法爲什麼這可能是？在遠程服務器上，當我們重新啓動應用程序池時，我們看到它需要36秒。MVC 4應用程序渲染時間與Visual Studio 2012

所以問題是，是否花了很長的時間，因爲IIS分配資源到網站或者我們的安裝有什麼問題嗎？每次我們調試項目時，我們的開發時間都會受到影響。生成，然後每次需要36s渲染我們正在調試的頁面。

來源

2013-03-05 safriss

幾個可能性浮現在腦海中：

查看編譯

通過當你在Visual Studio中的項目工作默認情況下，視圖點播編譯。雖然36秒似乎很長時間來編譯第一頁的視圖，但這可能是一個促成因素。如果您的頁面發生更改，則必須重新編譯。進行測量時，爲了消除這個作爲一個因素，你可以用文本編輯器編輯您的.csproj文件，並更改線路

<MvcBuildViews>false</MvcBuildViews>

到

<MvcBuildViews>true</MvcBuildViews>

（也可以是一般的一個有用的設置）。

其他初始化開銷

如果你是做多的初始化當你的應用程序啓動（可能是預加載從文件或數據庫中的一些數據），即初始化必須發生的每一次網絡服務器啓動或應用程序域回收。在Visual Studio中，我發現Web服務器可以在令人吃驚的時間重新啓動（對我來說）。添加一些日誌記錄，以查看您是否在特定的基準測試運行期間運行啓動代碼，並查看有多少開銷。

實體框架

出於某種原因，實體框架運行調試時多慢。如果您通過EF執行大量數據訪問，則可能會導致一些差異。

來源

2013-03-05 20:51:49

我做的第一件事是改變MVCBuildViews =「true」，但沒有改變任何東西。關於預加載數據，是捆綁嗎？那是automapper配置嗎？ – safriss 2013-03-05 21:07:04

捆綁應該不會超過幾個甚至幾百毫秒。在DEBUG模式下（基於web.config設置，而不是VS中的構建設置），捆綁實際上並未完成，而是捆綁中的文件通過未改變的方式傳遞。所以如果有什麼DEV會更快。對於預加載數據，我的意思是你可能會從你的數據庫加載數據或者在'Application_Start（）'中加載類似的數據。無論如何，我會測量在Application_Start（）中花了多少時間。 – 2013-03-05 21:37:51

當我們直接在頁面上放置腳本而不是在調試模式下使用綁定功能時，我們的啓動似乎要快得多。這個鏈接（http://todd-carter.com/post/2012/06/10/mini-me-fication-in-system-web-optimization-rc-is-evil/）似乎說同樣的事情，但它似乎微軟已經更新了這個，但我不太確定。我們沒有使用rc版本。 – safriss 2013-03-05 21:56:21

當你說「跑」時，我假設你的意思是調試。調試重建項目，然後一旦它加載瀏覽器，首次加載的所有標準初始化必須每次完成。事實上，需要與服務器上的應用程序池旋轉時間相同的時間（36秒）似乎證明了這一點。

FWIW，你只需要需要在每個Visual Studio會話中調試一次你的項目，讓IIS Express啓動。之後，您可以簡單地重建項目並在（不使用Visual Studio中的調試）之後直接刷新瀏覽器以測試更改。而且，如果您對任何* .cs文件進行了更改，則只需重新構建。 Razor視圖，web.config等將反映它們在下一頁加載時的更改，而無需重建。以這種方式失去唯一的東西就是調試能力，顯然是這樣。你只會得到一個標準的死亡黃頁，而不是自動跳到Visual Studio中有害的代碼。但是，我發現除非真的需要調試，否則這種方法開發起來要快得多。

來源

2013-03-05 21:18:18

MVC 4應用程序渲染時間與Visual Studio 2012

回答

相關問題