2012-01-29 46 views
6

鑑於此處的圖表,我應該看什麼來確定瓶頸?正如您所看到的,請求在負載下平均接近14秒,其中大部分時間歸因於New Relic分析數據中的CLR。在特定頁面的性能細分中,它將大部分時間歸入WebTransaction/.aspx頁面。什麼perfmon計數器可用於識別ASP.NET瓶頸?

stats captured by new relic during load test

stats for a page

+0

可能會延遲從數據庫中讀取此頁面上的標準會話鎖定。正如我看到橙色也是。 – Aristos 2012-01-29 20:30:58

+0

@Aristos能否詳細說明「標準會話鎖定」的含義? – RyanW 2012-01-29 20:34:10

+0

我的意思是這樣的:http://stackoverflow.com/questions/8989648/replacing-asp-nets-session-entirely當你使用會話在頁面上鎖定所有頁面,直到這個頁面因爲會話數據而結束處理。 – Aristos 2012-01-29 20:42:27

回答

3

我看到,該數據庫也(橙色)readed,這是接縫處的所有網頁的一個具有延緩因爲鎖的頁面的其餘部分是會議提出的頁面。

你還可以閱讀: Replacing ASP.Net's session entirely

我的建議是完全刪除會議呼叫,如果這是不可能的,找一個其他的方式在數據庫中你的自我的地方保存。

其實在我的網頁中,我已經提出了所有三種可能的選擇。 1.我打電話給網頁。 2我做了完全自定義的會話,它們是連接到用戶cookie的值,最後是3.我製作了遠離會話的線程,他們在後臺進行計算,當他們完成時我顯示結果。

在某些情況下,計算是在沒有會話的情況下調用頁面的iframe上完成的,稍後我會顯示結果。

1

在Pro版本中,您可以使用事務跟蹤,這有助於精確確定問題發生的位置。