其中C＃多線程選項使用

全部 -其中C＃多線程選項使用

更多的方法問題。我有一個Web服務，我需要從客戶端機器進行性能測試。所以本質上我正在編寫一個快速的WPF多線程應用程序（裏面有一個量表/速度表）來直觀地表示請求/響應時間。事件驅動 - 所以當我點擊一個按鈕 - 應用程序將開始提出請求。我只關心請求/響應花了多少時間，而不是現在的resposne值本身。

這是我目前思考的過程：

1）我需要創建儘可能多的線程，我可以（這我的客戶機可以處理），並衡量性能。 2個選項我可以考慮 - 創建一個新的Thread機制（所以我可以完全控制該線程）或使用backgroundworker機制（這樣我可以將該值從後臺處理傳遞迴UI）。假設 - 將不得不遍歷線程創建代碼 - 因此可以爲這兩種方法創建多個線程。

2）不需要任何進展報告，因此這不是標準用於選擇多線程方式

3）是否需要一個回調方法 - 因爲這應該傳回的值（取爲請求時間/響應web服務）

4）當我更新一個值的變量 - 將利用任何一種可用的同步方法。

5）沒有真正使用4.0框架中的任務API - 但那是我應該考慮的。

上述方法看起來不錯嗎？或者我錯過了什麼嗎？

真的很感謝任何幫助！

來源

2013-03-14 Patrick

是的，是的，是再一次的任務！任務是驚人的，整個任務的任務只是一個簡單的PLINQ循環，創建webrequests並等待響應。 – 2013-03-14 17:38:02

@BenjaminGruenbaum +1 PLINQ。我已經在幾次使用它，這對於這類事情來說是非常容易和很棒的。 – 2013-03-14 17:40:27

完全同意@BenjaminGruenbaum – 2013-03-14 17:40:55

很多人推薦任務，我認爲這是一個好主意。我不介意使用裸露的線程，並且至於應該使用哪一個線程，要麼會很好。需要注意的主要問題是異常處理行爲，這在兩者之間有所不同。如果你在一個典型的線程未處理的異常，它會拉低你的過程，所以你可能希望有這樣的事情（只不是簡單化;））：

int errorCount = 0; 

void Run() 
{ 
    Thread t = new Thread(delegate() 
    { 
     try 
     { 
      // your code 
     } 
     catch (Exception) 
     { 
      Interlocked.Increment(ref errorCount); 
     } 
    }); 
}

在另一方面，任務有更多受控的錯誤處理方式 - 當您調用Task.Wait函數時，它們會將它們包裝在AggregateException中。

我正在考慮你的情況的異常，特別是因爲我認爲你會在壓力測試期間結束超時錯誤。

Parallel.ForEach可能也值得一看，但老實說，既然你正在嘗試一個壓力測試而不是現實世界的場景，我可能會避免它來確定我一次運行多少個線程 - 我相信PLINQ的東西在客戶端做一些負載平衡。

所有這些方法的回調方法都很容易。我只是使用方法調用，而不是傳遞迴調，但這是一個實現細節。

我會遠離BackgroundWorker，因爲它實際上意味着與UI相關的異步操作，並且在這個特定的上下文中可能有點臃腫。

來源

2013-03-14 18:09:31

任務不僅僅是線程。 Eric Lippert在他的博客中多次表達了這一點。當你啓動一個任務時，它可能不會觸發一個線程（例如，它可能會使用一個事件，例如，在HTTP請求的上下文中，基於事件的方法可能比基於線程的方法好得多 – 2013-03-14 20:55:09

這值得了解。你能提供參考嗎？ – 2013-03-14 21:06:09

其中C＃多線程選項使用

回答

相關問題