2010-03-06 95 views
2

我爲一個已開發超過一年的項目做出了貢獻,並且我最近也加入了這個項目。C#代碼優化,剖析,應用程序優化

應用程序存在性能問題。

我知道有幾種分析工具,優化方法,比如找出瓶頸並優化它們。我很熟悉算法,運行迭代次數等。

我們正在使用C#,面向對象的dbms,應用程序有很多寫入和更新,至於緩存;速度緩存。應用程序將部署在大約100臺專用大型機器的後面,後者是可以處理每秒400K請求的昂貴負載平衡器,並使用64 GB RAM的數據庫服務器進行復制。這是他們的擴展策略。

+2

那裏有問題嗎? :) –

+2

你能否提出一個更具體的問題,例如你是否要求分析器建議? – itowlson

+0

你會在哪裏看,以及如何開始讓這個應用程序運行得更快? – DarthVader

回答

2

所以基本上問題是如何找到瓶頸。性能分析是一種方法,如果使用正確,通常工作正常。專注於包含最高時間的堆棧,以找出哪個組件是問題,專注於定位問題功能的時間。再看看執行次數,你經常會發現在那些經常執行方式的小函數中有驚喜。

另一種方法是性能計數器,這是我的最愛,因爲創建遠不如分析,並且可以在生產部署中一次又一次地使用和重複使用。我將計數器慷慨地添加到我的代碼中(請參閱Using XSLT to generate Performance Counters code以避免輸入大量重複代碼)並通過調用IncrementXXX來對代碼進行測試。增加性能計數器非常便宜,以至於代碼可以保留在發佈生產代碼中,這就是爲什麼我更喜歡這種方法。比如說我有一段代碼可以進行數據庫調用,然後是一個Web服務請求,然後是另一個數據庫調用。總體來說是緩慢的,但其中?我可以儀器這樣的代碼:

void MyFunction() 
{ 
    CountersManager.IncrementMyFunction(1); 

    CountersManager.IncrementFirstDBCall(1); 
    dataAccess.FirstCall(); 
    CountersManager.IncrementFirstDBCall(-1); 

    CountersManager.IncrementWebCall(1); 
    webRequest.MakeCall(); 
    CountersManager.IncrementWebCall(-1); 

    someCode.. moreCode; 

    CountersManager.IncrementSecondDBCall(1); 
    dataAccess.SecondCall(); 
    CountersManager.IncrementSecondDBCall(-1); 

    CountersManager.IncrementMyFunction(-1); 
} 

這是最簡單的儀器,它容易加入,雖然信息提供是最小的,它可以深入瞭解發生了什麼。假設我收集了性能計數器,並且我發現MyFunction計數器的大部分示例爲500,FirstDBCall計數器爲50,WebService計數器爲300,SecondDB調用爲50.這告訴我平均來自MyFunction中的500個調用,在網絡通話中捕獲了300個,所以這是最花時間的地方。但我可以更進一步,添加計數器來衡量發生的時間(增加AverageTimer32 類型的計數器的AverageBase一個),並且分析會給我平均操作持續時間。等等等等。

最後但並非最不重要的一點,您可以查看所用產品中所有現有計數器。缺點是,瞭解在哪裏看,以及如何解釋你看到的數字需要知道上述櫃檯,或獲得良好的故障排除技巧。實例中有很多像SQL Server這樣的產品,但是您使用的其他產品可能更難以找到有關此主題的良好文檔。

2

以性能分析器開始。我目前最喜歡的是紅門螞蟻。我也使用JetBrains dotTrace,但我更喜歡ANTS。

除非您有來自性能分析器的實際性能數據,否則您只會猜測應用程序需要調整和更改的位置。