3

考虑一个大任务,它可以分解成数百个独立运行的小任务。更具体地说,每个小任务都是发送一个轻量级的网络请求并决定从服务器收到的答案。这些小任务预计不会超过一秒钟,并且总共涉及几台服务器。

我想到了两种使用 Executor 框架来实现它的方法,我想知道哪个更好以及为什么。

  1. 创建一些,比如 5 到 10 个任务,每个任务都涉及进行大量发送和接收。
  2. 为每个发送和接收创建一个任务(可调用或可运行),并安排所有任务(数百个)由执行程序运行。

很抱歉,如果我的问题表明我懒得测试这些并亲自看看什么更好(至少在性能方面)。我的问题,在寻找这个具体案例的答案时,有一个更普遍的方面。在这种情况下,当您想使用执行器来执行所有调度和其他事情时,创建大量小任务还是将它们分组为更少数量的大任务更好?

4

2 回答 2

3

是创建大量小任务还是将它们分组为更少数量的大任务更好?

很难用这样的问题一概而论,但在你的情况下,我认为创建一些每个都做 5 到 10 件事的任务然后将其提交给执行者服务是没有意义的。

我会将所有工作作为一堆单独的小任务提交给ExecutorService. 我认为从对象/代码的角度来看,这将使任务更加清晰。他们不必拥有一组请求/响应,可以专注于发出一个请求并处理一个响应。

如果您不想将并发请求发送到特定服务器,则有一个例外。然后让一个任务为特定服务器执行所有请求/响应并为每个服务器提交一个任务是有意义的。

于 2012-10-03T21:38:22.903 回答
2

一般来说,我会说较小的任务更好,因为它们就像模块并且可以以所需的方式组合,即使需求发生变化。

但是,如果它们只能作为一个块执行,那么您可以更好地了解一项大任务。

性能当然也是一个问题。但这在很大程度上取决于您的服务器/机器的 CPU 数量和整个系统的负载。即使我们知道,您到底在做什么,您也需要进行测试以确定什么更有效。但请记住,任务的初始化和管理也需要一些时间,如果您的操作非常小,您可能会在任务管理上投入比实际执行更多的时间。

对于需要处理请求的应答服务器来说,并行运行所有(小)任务也可能被证明是困难的。请记住,Web 服务通常也对它们可以服务的并行请求数量有限制。

于 2012-10-03T21:47:05.407 回答