使用應用程序的多個實例的性能改進

我有一個性能敏感的.net應用程序。使用應用程序的多個實例的性能改進

它能夠並行線程化多達32個線程。我們需要進一步改進它。增加線程可能並不真正有幫助，因爲隨着我們增加線程數量，嘗試處理的失敗次數增加。

我的問題在這裏，

有什麼選擇吃剩的，以提高性能？
如果我運行同一應用程序的每個在parellel中運行32個線程的兩個實例，是否會有任何可能的改進？考慮到每個應用程序將運行在不同的AppDomain中，這只是一個瘋狂的想法。

來源

2010-10-12 SaravananArumugam

它是CPU綁定還是I/O綁定？你的機器有多少個CPU /內核？ – 2010-10-12 15:29:55

你的CPU利用率如何？你是否已經飽和了所有核心？如果你是，添加更多的線程將無濟於事;您必須優化代碼的基本性能，或向計算機添加更多內核。 – 2010-10-12 15:31:39

應用程序inturn必須調用WCF服務。所花費的時間和成功的過程和時間主要取決於服務。服務呼叫同步發生。 – SaravananArumugam 2010-10-12 15:57:42

最好的辦法是在進行任何更改之前嚴格測量性能並確定瓶頸。在問題中拋出額外的線程或進程不太可能導致最佳的解決方案。從這裏開始extensive .Net profiler information。

爲什麼32個線程是一個幻數？這是否給你比31/30/29等更好的吞吐量？

當他們不工作時，那些線程在做什麼？在任何給定的時間內，不會有比系統中的處理器內核數量多的線程。如果你是CPU綁定的，那麼添加更多的線程會適得其反。

涉及多少上下文切換開銷？

什麼是您的外部瓶頸候選人 - 直接I/O，網絡，數據庫？你還沒有太多的關於應用程序的實際功能。

你的線程是否共享資源？單個共享數據項可能是一個重要的瓶頸，再次，添加線程在這種情況下不起作用。如果可能，請使用thread-local替換共享數據。

來源

2010-10-12 15:34:31

瓶頸在於應用程序調用的WCF服務。服務inturn必須與SQL服務器進行交談以獲取結果。 – SaravananArumugam 2010-10-12 15:58:49

聽起來像瓶頸在服務和/或數據庫中，如果是這樣，你不能做很多事情（除非你也擁有系統的那部分）。如果這是一個緩慢的數據庫，服務是否可以緩存全部或部分數據以避免在每次調用時訪問數據庫？另外 - 你可以改變以異步模式調用服務嗎？如果是的話，你應該可以用較少的線程獲得相似的性能。 – 2010-10-12 16:02:42

使用應用程序的多個實例的性能改進

回答

相關問題