在ASP.NET應用程序中消耗超過65％的時間是什麼？

我有一個.Net Framework 4.0，ASP.NET，ASP.NET MVC 3 Web應用程序託管在Windows 7/IIS 7.5上。本機啓用IIS日誌記錄，並設置爲登錄W3C模式。在ASP.NET應用程序中消耗超過65％的時間是什麼？

該應用程序通過使用發佈配置進行編譯，並已部署到IIS，並明確指定了<compilation debug='false'屬性集。 Web.config指定使用基於SQL Server的會話狀態。

我在BeginRequest和EndRequest事件中分別在Global.asax中添加了以下語句。結果即「sw.Elapsed.TotalMilliseconds」被存儲在值的應用程序級別列表中。我通過一個調試頁面轉儲這些值，並獲得相同的平均值。

// in BeginRequest 
HttpContext.Current.Items.Add("RequestStartEnd", System.Diagnostics.Stopwatch.StartNew()); 

// in EndRequest 
var sw = (System.Diagnostics.Stopwatch)HttpContext.Current.Items["RequestStartEnd"]; 
sw.Stop();

我創建了一個負載測試，對20個用戶的併發用戶負載，針對此應用程序運行單個請求。該測試在Visual Studio 2010 Ultimate版本中運行。

運行負載測試後，我得到的秒錶所記錄的平均時間爲681毫秒。根據IIS對這些請求的平均時間（我在運行負載測試前清除了所有日誌）是2121毫秒。每個IIS的平均時間與Visual Studio負載測試報告中顯示的值相同。

根據IIS日誌/ Visual Studio報告，秒錶所花費的時間僅佔用時間的32％。另外68％的時間去哪裏？

更新1： 我將會話狀態設置爲InProc並重新運行負載測試。在這種情況下，秒錶報告的平均時間和IIS日誌報告的平均時間之間的差異增長到70％以上！所有這些時間在哪裏？

更新2： @Peter - 我嘗試了失敗的請求，通過把一個跟蹤規則登錄的200下一頁狀態代碼跟蹤，我跑了20個併發用戶的負載測試約1.5分鐘。通過最近的50個跟蹤文件，發現該報告中的「Time Taken」字段的範圍爲750毫秒到1300毫秒。 Visual Studio報告顯示平均值。時間爲2300ms。在報告中，使用緊湊視圖，我看到在以下轉換之間花費的時間變化：（1）AspNetStart - > AspNetAppDomainEnter （2）ManagedPipelineHandler-start ManagedPipelineHandler-end。（2）項可能是我的應用程序的代碼。依照失敗的請求日誌（即1300ms）和平均值，最大時間仍然有很大差異。如Visual Studio 2300ms所示，耗時。如何找到這個會計？感謝這個偉大的提示！

來源

2011-08-11 Dhwanil Shah

你應該看看分析你的代碼。它將爲您提供比基於秒錶的基於性能計數器更細緻和直接可用的數據。 –

@Merlyn - 我使用的是Visual Studio 2010 Ultimate分析器。將嘗試打開「顯示所有代碼」查看報告。但是，我懷疑這個問題可能存在於IIS而不是ASP.NET中，因此可能不在分析中。懷疑背後的原因是，秒錶計時取自ASP.NET的請求開始和請求結束事件。 –

您是否考慮過ASP.NET之外的系統級因素？例如IIS開銷，網絡？增加了更詳細的答案。 –

有一種更好的方式來看看你的應用程序的內部結構，通過使用「失敗請求跟蹤規則」

http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/

這樣，您可以完全地按照你的應用程序在IIS

做什麼

來源

2011-08-11 11:41:40

運行負載測試的時間有多長？如果你在windows 7下運行它，你可能會得到與windows服務器不同的結果。您可能會遇到突發負載下分配給線程池的線程問題。 .Net會立即將線程分配給線程池min，然後慢慢分配給線程池max。我相信客戶端操作系統的默認設置與服務器操作系統的默認設置不同。可能在客戶端操作系統上，默認最小線程設置等於機器上的內核數量，這意味着.net將緩慢分配更多線程以滿足爆發負載。

一個簡單的檢查就是讓你的負載測試運行更長時間，看看你的2個測量值之間的差距是否縮小。

來源

2011-08-17 17:45:44

測試是在Windows 7機器上使用IIS 7.5進行的。負載測試在20個用戶的恆定負載下運行。我會試着在同一臺機器上運行一段較長的時間，然後回傳結果。 –

以下是有關如何更改最小/最大工作者/ io線程設置的信息。 http://msdn.microsoft.com/en-us/library/7w2sway1.aspx。要知道的一個半陷阱是你需要禁用自動配置，否則你的新值將被忽略。 –

您的測試中的另一個考慮因素是，如果您開始感冒站點，第一個請求將導致與突發事件相關的各種時間處罰等。如果您在突發請求時開始感冒，它們將排隊等待該網站已準備就緒。所以特別是如果你沒有讓你的網站變暖並且測試時間很短，你的結果將會出現偏差。 –

如果你的加載時間很長，它可能與幾件事情有關，如果你有大量的IO操作，它可以影響這個如果你正在用orm進行數據庫查詢嘗試分析你的sql語句vs與一個sql profiler或在profiler中建立的sql服務器，如果你得到很多個人查詢，你可能要考慮使用一些包括在你linq查詢來捆綁你的一些數據到單個查詢

你可能也想考慮考慮使用異步控制器來提高響應時間，如果您有大量IO操作，那麼您的應用程序不會持續等待每個io操作完成請參閱wintellect.com/CS/blogs/jprosise/archive/2010/03/29/…

還有更好的解決方案在那裏記錄比iis日誌記錄，因爲它是一個相當古老的組件，你可能想看看log4net的更一般的日誌記錄或elmah記錄錯誤和異常，因爲這些解決方案可以捆綁一堆日誌條目，並在單個操作中寫幾個也提高IO性能

來源

2011-08-18 04:50:02

等待代碼中的IO應該在秒錶計時中考慮 - 所以在IIS中報告的內容和秒錶報告的內容之間應該有差距。 –

我會建議尋找MvcMiniProfiler。這是一個NuGet包，你可以添加和連接（幾乎毫不費力地），真正打破了你的MVC應用程序中各個點的執行時間。您可以看到每個請求的實時視圖以及任何瓶頸所在的位置。

更多信息：

來源

2011-08-18 20:07:48

其最有可能是在託管管道開銷的組合使你網絡（即使是本地主機或127.0.0.1）可能是「丟失」時間可以考慮的地方。

你提到的IIS日誌符合你的Visual Studio負載測試人物 - 無論是那些涉及到網絡堆棧和管理pipleline。
您的秒錶代碼僅在ASP.NET上下文中執行（在ASP.NET執行開始之前和結束之前只執行），並且不考慮處理TCP網絡請求的IIS開銷 HTTP通過管理的管道和TCP堆棧，請求和響應的傳輸時間爲。
[編輯]如果您的ASP.NET頁面執行時間非常快，例如，這個比例被誇大了，它不會消耗大量的CPU相對於其他TCP堆棧和管理流水線，它將整理HTTP請求給你

來源

2011-08-21 15:43:04

在ASP.NET應用程序中消耗超過65％的時間是什麼？

回答

相關問題