这非常令人费解。对于给定的作业，一台物理机器在大约49分钟内完成该作业。如果我添加另一台物理机器，那么现在两台机器都完成了部分工作，这需要更长的时间——53分钟！两台机器都在第三台机器上的数据库上运行
是什么原因造成的我本以为这两台机器能在一台机器所需时间的一半左右(大约25分钟)内完成任务。。。
让我更详细地描述设置：
这涉及3台Windows 7计算机(3台独立的物理计算机)。每个具有8个核心
每台机器上都运行一个Wildfly 10实例。
在线服务器-机器1:-用户通过web界面与此机器交互
*此计算机还承载SQL Server上的数据库
*当用户请求运行某个作业时，代码会分解将作业分解为较小的任务。每个任务都被分配了一个id。然后会有一条JMS消息发送到此机器上的队列中。该消息包含任务id。
*所以基本上工作是被划分的，信息被写入DB，并且现在需要执行这些任务。它们可以按任何顺序执行。
批处理服务器-机器2和批次服务器-机器3(两台独立的机器)
*这些机器中的每台都有自己的Wildfly 10实例在运行。
*每台都配置为使用来自远程队列的消息在线服务器(机器1)中定义
*它通过MDB使用池连接工厂使用远程连接器来实现
*两台机器中的MDB都配置为maxSessions=10(也尝试了8)
*在onMessage方法中收到消息后，代码将获得任务id，然后它从数据库(在线服务器(机器1)上)获得任务信息并执行与该任务id相关联的工作。
观察结果：
- 如果机器3处于脱机状态，并且作业的所有任务都由机器2执行，则需要49分钟才能完成作业
- 如果同时涉及机器2和3，则需要53分钟才能完成作业
- 查看目标DataSource(在任意一台机器的wildfly控制台中)也会显示：
可用Conencs:248
活动：3
使用的最大值：17 - 当机器2和3都在处理作业时，在机器2上完成任务的平均时间比只有机器2处理作业时更长
- 任务在两个批处理服务器之间分布得非常好，大致相等
-
联机服务器(也是数据库服务器)甚至还没有达到CPU的完全利用率。
-
数据源在Wildfly中配置如下：
<datasource jndi-name="java:/jdbc/dbconn" jta="true" pool-name="MSSQLDS1" enabled="true" use-ccm="false" use-java-context="true" statistics-enabled="true"> <connection-url>jdbc:sqlserver://wilxs185458-ftx:1433;DatabaseName=K11.2N;selectMethod=direct</connection-url> <driver>sqlserver1</driver> <pool> <min-pool-size>100</min-pool-size> <max-pool-size>250</max-pool-size> </pool> <security> <user-name>sa</user-name> <password>password</password> </security> <statement> <track-statements>true</track-statements> <prepared-statement-cache-size>1000</prepared-statement-cache-size> <share-prepared-statements>true</share-prepared-statements> </statement> </datasource>
我还尝试了MDB的配置maxSessions(有多少线程并行处理任务)，并且只在一台Batch机器上运行
我观察到，无论我使用maxSessions 2、4还是8，总工作量都在大约相同的时间内完成
我还可以从日志中看到，线程根据maxSessions并行运行(正如预期的那样)，当一个线程完成时，它会立即被分配另一条消息(因为每个线程都记录它开始处理onMessage的时间和完成它的时间)
完成处理任务所需的平均时间(处理onMessage方法所需的时间)与maxSessions成比例。
如有任何帮助，我们将不胜感激。
2017年1月11日添加的信息：
我使用了YourKit Java Profiler(性能分析器)，并运行了两次相同的作业。在这两种情况下，只涉及Batch Server机器1。第一次运行时，MDB注释为maxSessions=8，第二次运行时maxSessions=4。
甚至看一下java.lang.String.toLowerCase()方法，
在处理作业期间，该方法被调用了312k次，但总时间为55174毫秒，而不是3003毫秒(8个线程对4个线程)。因此，将线程数量增加一倍使这种方法的速度减慢了一个数量级！
原来问题与网络有关。刚刚托管数据库的第三台机器连接到了一个墙上的插座，这可能会把它放在一个更糟糕的网络上或类似的地方。有一次我把它的电线换到另一个插座上，一切都很顺利。(不确定技术条款)。关键是我运行数据库的机器的网络带宽不好，我发现这一点的方式是：我使用远程桌面从两台Wildfly主机中的一台连接到该数据库主机，并将一个大文件从数据库机器复制到Wildfly机器，并在资源监视器中查看网络性能。我观察到最大值约为10Mbs。那是危险信号。在更正了数据库机器的物理连接后，此文件传输的速度约为100Mbs。。。这也解决了上面的问题