2009-10-17 65 views
3

我開發了一個使用Asp.net C#3.5的網站,現在我覺得有些頁面正在加載reeeaaally slooooow。我現在需要開始瀏覽網站,並試圖找出讓它如此緩慢的原因。但我不知道從哪裏開始,最可能導致問題的是什麼?當你試圖找出哪裏出了問題時,你通常會從哪裏開始?asp.net網站上的性能下降,從哪裏開始尋找問題?

一頁,這是非常緩慢的使用以下:

  • Asp.net C#3.5
  • AjaxControlToolkit(http://www.asp.net/ajax/AjaxControlToolkit/Samples/
    • RoundedCornersExtender
    • CollapsiblePanelExtender
  • 兩種不同UpdatePanels
  • 11個連接到MySql數據庫(一個很重,使用一些聯合和內部聯接)
  • 大多數到數據庫的連接導致填充FormViews或GridViews,所以完全我有2個formview和6個gridviews在頁面上(每gridview顯示最多10個項目)
  • CSS文件可以減慢網站?我使用的CSS文件大約60kb。

可以使用AjaxControlToolkit使網站變慢嗎?有沒有更好的方法在網站上使用JavaScript?

我知道您不可能幫助我找到緩慢加載的問題,但您會在哪裏開始尋找問題? DataControllers? AjaxControlToolkit? sql?這是一個簡單的方法來查明在mysql中的查詢是否很慢?什麼是慢?對於大型查詢,0.3秒的速度慢嗎?

正如你所看到的,我有很多問題,也許你可以幫助我開始正確的工作方向,非常感謝你的幫助!

+0

也許您的網站在第一次加載時速度較慢,因爲應用程序池已被回收,您可以嘗試下面的代碼,以使您的網站始終保持在這裏溫暖:[http://stackoverflow.com/questions/27339997/how-to-always-您的熱身-ASP淨網站網絡表單-MVC(http://stackoverflow.com/questions/27339997/how-to-always-your-warm-up-asp-net-websites-webform-mvc ) – VnDevil 2014-12-07 15:57:07

回答

1

我處理這種事情時的一般方法總是一樣的。我開始刪除功能 - javascript/css/include文件 - 直到頁面變得更加快速響應 - 通常我會將頁面恢復到最低複雜度並從此處構建。將它們逐個添加回來,您應該能夠確定瓶頸的位置。您還可以使用像(對於MySQL)慢速查詢日誌等工具來識別有問題的查詢。將你的查詢抽象出來並在phpmyadmin(或類似的)中運行它們也可以幫助你識別哪些查詢是問題,如果是這種情況。

我想你需要確定的第一件事是什麼是「緩慢」的頁面,它是渲染時間?加載時間?確定這應該給你一個很好的起點。

0

我會開始檢查這些SQL查詢執行多長時間。不知道爲MySql調用SQL Profiler類型的工具。如果這不是罪魁禍首,您可以創建TraceAttribute,如here所示,以查看您的每個方法執行多長時間。如果這不是罪魁禍首,那麼可以使用類似FireBug或Fiddler的東西來查看網站的每個部分需要加載多長時間以及每個請求需要多長時間。你也可以使用Tracing而不是Post Sharp,但是當你有一把錘子時,每個問題看起來都像是釘子。

1

首先,您需要進行一些分析/測量來確定應用程序的哪個部分比較慢,G:

  • 長時間運行的數據庫查詢
  • CPU /存儲器使用的全球信息網/ DB服務器上的web服務器和客戶端(瀏覽器)
  • 花費的時間來呈現頁面之間轉移數據的
  • 量在瀏覽器(JavaScript)的
+0

謝謝!我在共享主機上,所以我看不到長時間運行的dbs或cpu /內存。但我會開始逐個測試我的查詢,然後我可以嘗試像Yuriy提到的螢火蟲。 – Martin 2009-10-17 12:40:07

4

你可以開始添加Trace="True"到您的<%@ Page %>指令,看看你的頁面大部分時間;也檢查你的web.config和配置debug已禁用。

您還可以使用Performance Monitor,以幫助您確定您的應用程序主要瓶頸

+0

哦,我的天啊,我不敢相信我忘記了將debug設置爲false。感謝您的簡單建議,我只是將我的網站的加載時間縮短了一半!也會考慮跟蹤。 – Yetti 2012-04-13 14:56:09

3

不要忘記

ASP.NET Tracing

爲可能是第一個,也是最簡單的事情,開始診斷ASP。 NET問題。

如果你想獲得深入的多一點,不要忘了嘗試:

ASP.NET Health Monitoring

從你說的話,不過,就個人而言,我會考慮可能減少這些數據庫連接。數據訪問一直是主要瓶頸(或可能)。對於一個頁面來說,11個連接是相當多的,特別是如果你說一個或多個連接「重」工作的話。該頁面可以分成兩個或更多頁面嗎?如果問題出現在頁面的的呈現中,則ASP.NET Tracing的輸出在這方面應該會有所幫助。

CSS文件雖然在60kb處很大,但可能是最不可能的罪魁禍首,因爲大多數瀏覽器會在第一次請求後緩存CSS文件。