2012-05-03 29 views
3

首先抱歉,我不能更具體,因爲如果我可以然後我可能知道在哪裏看。我有一個使用AjaxControlToolKit的一堆網頁的ASP.net Web應用程序。在兩種環境下,頁面呈現的速度差異很大。在一個它超級緩慢採取~5 seconds呈現一個相對簡單的頁面,有兩個網格和一堆控件。我在任何地方看文章都說「檢查你的SQL」,但這不可能,因爲SQL perf在所有環境中都應該是通用的。我也縮小到頁面只是做一個基本的回發,沒有sql,仍然是問題的重現。用戶點擊選擇全部,我們檢查列表中的一堆項目。我爲此定了代碼,並且它的速度很快00:00:00.0002178ASP頁面性能很差,在各種環境下差別很大

兩個環境並排,同一地點,都有IE9,除了一個在W2K8上運行,一個在W7上。這是唯一真正的區別。在W7的頁面上相對快速渲染。

任何指針非常讚賞。

編輯:

更改調試爲false確實有積極的影響。

調試頁面時 真0.143363802770544 假0.0377570798614921

所以我下一步會做系統地查看應用程序的每個組件明白爲什麼我犯錯誤,SQL,ViewState的,等我會更新這個職位與我最後的調查結果對於那些感興趣

謝謝大家的幫助!

+0

這應該被標記爲WebForms而不是MVC? –

+0

WebForms,因爲他正在使用AjaxControlToolkit – Stilgar

+0

你可以給我們的URL檢查出來嗎? – Aristos

回答

0

我大概是第一次檢查,看看自己是否有「調試」模式在我的web.config接通

+0

是debug = true,讓我看看這個影響,看看它是否有所作爲,儘管我會已經預計debug-true的性能影響在所有服務器上都是相同的。 –

1

我會檢查以下

  1. 通過任務管理器檢查服務器上的CPU使用率(網絡應用和數據庫)。它是刷爆了

  2. 是服務器的物理內存不足 - 再任務管理器

  3. 是返回的頁面巨大的。這很明顯,但有時並非如此。純粹的HTML數量可以殺死一個頁面。這可能是隱藏的(ViewState,顯示元素:'無')或實際上在頁面上,但你很習慣看你看不到

  4. 把小提琴弄到它上面。你打電話給任何你不應該的外部資源嗎?也許有一個你依賴的Web服務,突然從某個特定的框中無法訪問。我們有一個推特Feed,它已經超時,完全殺死了一個網站。

  5. 做配置數據庫。你認爲這不可能,但你確定。你確定你確定嗎?你可能不會像like一樣進行比較,並且在沒有意識到的情況下在一次測試中帶回大量數據。

  6. 某些進程對頁面/數據長度非常敏感。例如,我有一個正則表達式完全失敗,並在頁面達到一定大小後將頁面計時。演出幾乎沒有拖延 - 它停止了死亡(寫得很糟 - 誰做了 - 呃我!)

  7. 物理盒子是否正在死亡。他們是否有任何其他的流程/站點正在殺死它。你和誰分享這個盒子?是硬盤在出路嗎?

  8. 防火牆可能很淘氣。通過重新啓動物理防火牆,我們看到了性能的大幅提升。你可以跟蹤這些數據包嗎?

任何會有更多 - 性能調試可能是一門藝術。但是,嘿 - 我們都是藝術家,不是我們。