性能問題

我們正在運行一個ASP.NET應用程序，現在我們的流量增加了很多，導致用戶響應速度慢。我們已經優化了應用程序和數據庫，但仍未達到預期的響應時間。我們嘗試了ASP.NET緩存，但它也沒有幫助。我可以嘗試的其他選擇是什麼？我正在尋找一種可擴展的解決方案，以便在將來能夠處理更多的流量。性能問題

來源

2011-06-21 Ravian

移動到多個服務器？ –

您是否認爲您的Web服務器硬件資源與請求數量相關？如果您從Web服務器硬件資源的最佳功能獲得預期輸出，這可能也很重要。例如：額外的RAM可能是一個很好的選擇，如何使用性能計數器等事先做過研究 – DSharper

如果問題是您的數據庫 - 那麼你需要優化更好，更優的硬件，DBA分析等

如果問題是你需要配置文件，並找出究竟其中一個緩慢的Web應用程序緩慢發生。這裏的問題很模糊。下載ANTS配置文件或寫你自己的跟蹤輸出（螞蟻更容易恕我直言），看看你的應用程序放緩。這是因爲會話鎖，數據庫，linq查詢執行時間和時間（例如調用query.Count（）將每次重新執行查詢）等等等

檢查您的viewstate大小 - 使用工具fiddler調查頁面大小，第一個字節的時間等。

這是一個模糊的問題，但這些是一些基本的項目。

我們需要更多的信息，但這應該讓你開始。

來源

2011-06-21 05:09:23

「升級」的答案不告訴我們在哪裏或什麼。您的驅動器是否針對讀取的簇大小進行了優化您的文件組是否爲讀/寫等進行了優化。但是，你提到你正在將會話存儲在sql server中。那麼現在就會發生這種情況，因爲潛在每個請求都有數據庫開銷。狀態服務器應該有點幫助：http：//www.codeproject.com/KB/aspnet/p2pstateserver.aspx所以如果沒有，那麼你的問題可能在別處。爲什麼不禁用某些控件的viewstate並將緩存中的數據重新綁定，例如作爲測試（或一起禁用） –

我想問候的@AdamTuliper的答案強調的ViewState的

你可能有很多是逐漸加入龐大的數據GridView的的。考慮如果不需要，關閉ViewState。含義：如果用戶不與gridview交互（通過選擇一行，更新等），那麼不需要網格視圖在服務器和客戶端之間來回切換。

但是，如果情況並非如此，那麼我們需要更多信息才能提供幫助。

來源

2011-06-21 05:13:36 Ahmad

我們已經將硬件升級到了最新技術。我們將會話存儲在MSSQL服務器中，我認爲第一個瓶頸是SQL Server，因爲它似乎不具備可擴展性。我們已經對SQL服務器進行了一些測試，當用戶數超過15000時會出現問題。我們已經嘗試會話狀態服務器，但它並沒有幫助我們的應用程序的一部分大量使用ViewState，我們正在努力減少VS的大小，但這是我們可以做的事情。我們正在嘗試編寫一個自定義VS商店，我們將把大型VS保留在本地緩存中，而不是保留在ASP.NET響應中。 – Ravian

Asp.net緩存本身有一些限制和性能問題。它不會使應用程序具有可伸縮性，因爲它在本質上處於進程中。但是，如果可擴展性是您主要關心的問題，那麼您需要實現分佈式緩存。分佈式緩存可以使應用程序高度可擴展。基本上，內存中分佈式緩存是一種緩存形式，它允許緩存跨越多個服務器，以使其可以擴大規模並提高事務處理能力。由於其架構，它也是一個非常可擴展的平臺。它分佈在多個服務器上，但仍然可以爲您提供單個緩存的邏輯視圖。我寧願代表我的經驗建議你NCache。欲瞭解更多詳情，請閱讀本文「improve asp.net app performance and scalability」。它會很好地幫助你。

來源

2011-08-10 11:24:50 Nelly

感謝Nelly，我們已經在評估NCache和其他第三方緩存提供商。 – Ravian

回答

相關問題