关于线程/后台工作者的问题

我有一个关于线程和后台工作者的问题,我希望你能帮忙。

我计划制作一个ftp应用程序,将文件上传到50台服务器。 用户不必等待每次上传在下一次上传之前完成,而是在寻找线程/后台工作者。 上传完成后,我想将上传“已完成/失败”的状态报告回UI。 根据我的理解,我将需要使用后台工作人员,因此我知道任务何时完成。 我知道使用线程我可以使用生产者/消费者队列或信号量来一次运行给定数量的线程但我不太确定如何使用后台工作人员来实现这一点。

所以我的问题是,什么是合理数量的后台工作人员控制上传一次运行,什么是排队其余的最佳方式?

上传文件的大小没有限制,因此可能非常小或几MB。

提前致谢。

编辑 – 我为每个运行同步的服务器测试了一个后台工作程序。 结果比单个背景工作者更快,但我不能说我完全适应同时运行50多个后台工作人员,并且由于服务器数量可能在未来增加,我决定坚持只看一个,这似乎足够快。 我将来可能会将工人数增加到2或3,但目前1似乎已足够。 感谢大家的帮助。

谢谢

这比使用信号量或生产者 – 消费者队列容易得多。

将所有任务放入队列中(不需要是线程安全的队列,只能在UI线程中使用)。

从1循环到N,取出任务并启动BackgroundWorker 。 (当开始的任务少于N个时,确保处理空队列)。 在RunWorkerCompleted事件中,更新UI,使其他任务出列,然后启动另一个BackgroundWorker

我会与它完全不同的方向,tbh。 你的应用程序应该获取文件并存储一次,响应客户端它已经获得它。 然后该文件应传播到其他服务器。 您可以通过多种方式执行此操作,但如果您希望它由同一应用程序控制(即未使用Windows服务等完成),那么一种好方法是使用消息队列(MSMQ或其中一个OS) 。

这里的瓶颈将是您的网络带宽。 如果您的本地上游连接速度太快,以至于您可以使两个或多个远程主机上的传入连接饱和,那么您将受益于并行运行多个上载。 如果没有,则它对总上传时间的影响非常小,因为它将由(文件大小*上传数量)/(本地带宽)决定。 换句话说 – 如果你一次上传一个,那就需要一个小时; 如果你并行上传20个,它仍然需要一个小时。 第一种方法的优点是,如果您失去连接,您只需要恢复/重新启动单个上载 – 无论连接丢失时正在进行中。

因此,我会使用一个后台线程依次将文件依次上传到每个服务器。 如果您使用.NET BackgroundWorker执行此操作,则可以在每个文件的末尾将其发送到ReportProgress(并且您事先知道要上载多少文件,以便您可以按百分比计算进度),并附加一些自定义状态到进度更新,通知用户上次上传是否成功。

确切知道的唯一方法是测试和测量,但机器之间的差异可能不同,主要取决于上行速度。

同时开始50名背景工作者有点高端,但并不是很多。 一种简单的方法是同时启动50个并测量内存消耗和上传速度。

如果FTP服务器每个都比客户端上行链路速度快得多,那么最有效的方法是一次只上传一个(或可能两个)。