2011-03-12 57 views
1

我有一個關於線程和後臺工作人員的問題,我希望你能幫忙。關於線程/後臺工作者的問題

我打算讓ftp應用程序將文件上傳到50臺服務器。在下一次開始之前,用戶不必等待每次上傳完成,而是在尋找線程/後臺工作人員。一旦上傳完成,我想報告上傳「已完成/失敗」的狀態返回到用戶界面。根據我的理解,我需要爲此使用後臺工作人員,以便我知道任務何時完成。我知道線程我可以使用生產者/消費者隊列或信號量一次運行給定數量的線程,但我不太清楚我如何能夠實現這一點與地面工作人員。

所以我的問題是,控制上傳立即運行的後臺工作人員的數量是多少,以及其他排隊的最佳方法是什麼?

上傳文件的大小沒有限制,所以這可能會很小或者最高達幾MB。

在此先感謝。

編輯 - 我爲每個運行同步的服務器測試了一個背景工作。結果比單個背景工作者要快,但我不能說我對於同時運行50多位後臺工作人員非常舒適,而且由於服務器數量未來可能會增加,所以我決定堅持使用一個,似乎足夠快。我將來可能會將工人數量增加到2或3人,但目前1似乎已經足夠。感謝大家的幫助。

謝謝

回答

1

這比使用信號燈或生產者 - 消費者隊列容易得多。

把你所有的任務隊列(不必是線程安全的隊列,它只會從UI線程中使用)。

從1到循環N,取出一個任務並啓動BackgroundWorker。 (當有少於N個任務時,務必處理空隊列)。在RunWorkerCompleted事件中,更新您的用戶界面,取消另一項任務,並啓動另一個BackgroundWorker

+0

嗨本,我決定用這種方法我用一個單一的背景工人在同一時間運行的應用程序。感謝fedor333的幫助 – fedor333 2011-03-28 10:13:18

1

這裏的瓶頸將是你的網絡帶寬。如果您的本地上游連接速度如此之快以至於您可以在兩臺或多臺遠程主機上使傳入連接飽和,那麼您將從並行運行多個上傳中受益。如果不是,那麼它對總上傳時間沒有什麼影響,因爲它將由(文件大小*上傳數量)/(本地帶寬)決定。換句話說 - 如果你一次上傳一個,則需要一個小時;如果你並行上傳20個,它仍然需要一個小時。第一種方法的優點是,如果您失去連接性,您只需要恢復/重新啓動一次上載 - 無論連接丟失時是否正在進行。

因此,我會使用單個後臺線程依次將文件依次上傳到每個服務器。如果您使用.NET BackgroundWorker來執行此操作,則可以在每個文件的末尾將其獲取到ReportProgress(並且事先知道要上傳多少個文件,以便可以按百分比計算進度),並附加進度更新的一些自定義狀態以通知用戶上次上傳是否成功。

+0

嗨迪倫 - 我決定使用一個後臺工作如你所說 - 由於fedor333 – fedor333 2011-03-28 10:14:37

2

我會用一個完全不同的方向,tbh。你的應用程序應該獲取文件並存儲一次,並回應客戶端獲取它。該文件應該傳播到其他服務器。你可以用很多方法做到這一點,但是如果你想讓它由同一個應用程序控制(也就是說沒有使用windows服務或類似的東西),那麼一個好方法就是使用消息隊列(MSMQ或者其中一個OS) 。

1

確切知道的唯一方法是測試和測量,但它可能因機器而異,主要取決於上行速度。

同時啓動50個背景工作者在高端位置上有一點點,但並不令人難以置信。一個簡單的方法是同時啓動50個所有內存並測量內存消耗和上傳速度。

如果FTP服務器是比客戶端上行速度最有效的將是隻需上傳一次在一個(或可能二)各快得多。