java - 仅对于更高的WAN延迟，在ActiveMQ中观察到3倍的延迟

Question

我正在对组织的ActiveMQ 5.8.0代理配置进行性能表征，重点是在仅包含两个代理的简单代理网络配置中，代理之间的WAN延迟的影响。我可以访问WAN仿真器设备，该设备可以使我在两个代理之间的网络链路上的每个方向上独立更改模拟的WAN延迟，同时使所有其他网络连接(尤其是客户端与其本地代理之间的网络连接)的标称延迟为0ms。

当WAN延迟为〜150ms或更低时，我看到的端到端延迟正是基于WAN延迟我们期望看到的，但是对于更高的延迟，端到端延迟是我们的三倍。期望。我已经搜索了Google，SO和AMQ邮件列表档案，但没有找到任何人在谈论这种行为，也找不到任何可以解释正在发生的事情的东西。

ActiveMQ设置:

非持久消息。没有事务，没有持久性技术的延迟，等等。

两个代理，它们之间具有WAN仿真器。此WAN仿真器不影响客户端和代理之间的通信，仅影响两个代理之间的通信。它正在创建模拟的延迟，但没有其他网络影响(数据包丢失，乱序数据包等)。

一个队列，用于从生产者到消费者的消息，一个排他答复队列，用于从消费者到生产者的响应。

一个连接到Broker 1的生产者，使用InOut模式的Camel，以最快的速度产生20KB消息，然后在发送下一条消息之前先使用排他答复队列的响应。

连接到Broker 2的一个使用者，也使用Camel消耗来自产生者的消息并回复到独占回复队列。

来自生产者的消息包含一个头值，消费者在其上具有选择器。生产者产生的所有消息都被消费者消耗。

因为生产者使用(同步)Camel InOut模式，所以在消耗了前一条消息的响应之前，不会产生下一条消息。这意味着预取缓冲区和生产者流控制不在这里。

因为我们的消息是非持久性的，所以我希望单向端到端延迟是该方向上的WAN延迟，再加上一个小的(2-5ms)常量进行处理，Camel的开销等，以及该回合。 -端到端的延迟是两个单向WAN延迟的总和，加上大约两倍的小常数(约5-10ms)。

相关配置摘要:

ActiveMQ配置文件，删除了不相关的样板内容:

<beans boilerplateSchemaStuff>
    <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">boilerPlateStuff</bean>

    <broker xmlns="http://activemq.apache.org/schema/core"
            brokerName="${broker.name}"
            useJmx="true"
            persistent="false"
            schedulePeriodForDestinationPurge="60000"
            networkConnectorStartAsync="true"
            cacheTempDestinations="true"
            timeBeforePurgeTempDestinations="300000"
            allowTempAutoCreationOnSend="true">
        <destinationPolicy>
            <policyMap>
              <policyEntries>
                <policyEntry queue=">" producerFlowControl="true" memoryLimit="10mb">
                  <pendingQueuePolicy>
                    <vmQueueCursor/>
                  </pendingQueuePolicy>
                  <slowConsumerStrategy>
                    <abortSlowConsumerStrategy abortConnection = "true"/>
                  </slowConsumerStrategy>
                </policyEntry>
              </policyEntries>
            </policyMap>
        </destinationPolicy>

        <managementContext>
           <managementContext createConnector="false" />
        </managementContext>

        <networkConnectors>
          <networkConnector name="REMOTE_QUEUES" uri="${broker.remote.uri}"
             networkTTL="3" decreaseNetworkConsumerPriority="true"
             conduitSubscriptions="false" dynamicOnly="true" />
        </networkConnectors>

        <plugins>
          <statisticsBrokerPlugin/>
          <discardingDLQBrokerPlugin dropAll = "true" dropTemporaryTopics = "true"
             dropTemporaryQueues = "true"/>
        </plugins>

        <systemUsage>reasonable limits, not believed to cause this issue since producer flow control isn't occurring</systemUsage>

        <transportConnectors>
            <transportConnector name="openwire" uri="tcp://0.0.0.0:${tcp.port}"/>
            <transportConnector name="stomp" uri="stomp://0.0.0.0:${stomp.port}"/>
        </transportConnectors>
    </broker>

    <import resource="file:${ACTIVEMQ_CONFIG_SC}/conf/jetty.xml"/>
</beans>

生产者Spring配置:

<beans boilerplateSchemaStuff>
   <bean id="messageGen" class="teststubs.MessageGenerator">
      <property name="name" value="MessageGenerator"/>
   </bean>

   <bean id="amqMessageThroughputProcessor" class="teststubs.AmqMessageThroughputProcessor">
      <property name="name" value="QueueResponseConsumer${token}"/>
   </bean>

   <bean id="token" class="java.lang.String">
      <constructor-arg value="${token}" />
   </bean>

   <camel:camelContext allowUseOriginalMessage="false">
      <camel:jmxAgent id="agent" disabled="true" />

      <camel:endpoint id="sendDestination"
         uri="jms:${destination.type}:PerfTest#{T(org.apache.commons.lang3.text.WordUtils).capitalize('${destination.type}')}?requestTimeout=10000&amp;replyTo=PerfTestResponseQueue${token}&amp;replyToType=Exclusive&amp;concurrentConsumers=1&amp;mapJmsMessage=false"
         xmlns="http://camel.apache.org/schema/spring"/>

      <camel:route>
         <camel:from uri="timer://sendTask?period=1&amp;fixedRate=true&amp;repeatCount=1" />
         <camel:loop copy="true">
            <camel:constant>10000</camel:constant>
            <camel:bean ref="messageGen" method="create20KbTimestampedMessage"/>
            <camel:setHeader headerName="Token">
               <camel:simple>ref:token</camel:simple>
            </camel:setHeader>
            <camel:to ref="sendDestination" pattern="InOut" />
            <camel:process ref="amqMessageThroughputProcessor" />
         </camel:loop>
      </camel:route>
   </camel:camelContext>
</beans>

消费者 Spring 配置:

<beans boilerplateSchemaStuff>
   <bean id="amqMessageThroughputProcessor" class="teststubs.AmqMessageThroughputProcessor">
      <property name="name" value="QueueConsumer"/>
   </bean>

   <camel:camelContext>
      <camel:jmxAgent id="agent" disabled="true" />

      <camel:endpoint id="receiveDestination"
         uri="jms:${destination.type}:PerfTest#{T(org.apache.commons.lang3.text.WordUtils).capitalize('${destination.type}')}?concurrentConsumers=1&amp;mapJmsMessage=false&amp;selector=Token='${token}'"
         xmlns="http://camel.apache.org/schema/spring"/>

      <camel:route streamCache="true">
         <camel:from ref="receiveDestination" />
         <camel:process ref="amqMessageThroughputProcessor" />
      </camel:route>
   </camel:camelContext>
</beans>

观察结果:

双向都具有低延迟(<= 100ms)，这正是我所看到的。对于每个方向100ms，单向端到端延迟大约为105ms，往返延迟大约为210ms。当我将每个方向的延迟增加到150ms时，它按预期开始(单向155ms，往返310ms)，但是经过了一段时间(从我所看到的几秒钟到几分钟)，延迟增加了两倍，达到单程455ms和往返910ms。这是延迟的突然增加；一条消息报告单程155ms和往返310ms，下一条消息和所有后续消息报告455ms和910ms，而不是延迟时间较长的消息。延迟跳跃时(在其他任何时间)，代理或两个客户端的日志中都没有错误。

进一步改变WAN延迟(单向延迟保持在150ms以上)会导致延迟立即变化，以保持 (3 x one-way WAN latency) + 5ms的单向端到端延迟和 (3 x (forward one-way WAN latency + return one-way WAN latency) + 10ms的往返端到端延迟。由于延迟的增加似乎与WAN延迟的变化成正比，因此可以肯定地说，这是由跨网络的东西引起的，而不是由生产者，消费者或两者之一引起的(固定)延迟引起的。经纪人。

因为我可以分别在两个方向上改变模拟延迟，所以我能够确定当两个方向具有相同延迟时我看到的3倍单向延迟实际上是 (2 x forward one-way WAN latency) + (1 x return one-way WAN latency)(正向单向端到端)与 1 x forward one-way WAN latency的期望值相比的最大延迟。将两者相减表明意外的额外延迟为 (1 x forward one-way WAN latency) + (1 x return one-way WAN latency)，表明在代理之间(也许也在每个代理与其客户端之间)每条消息发生一次意外的往返。也为响应消息找到了相同的结果。

可能的原因:

据报告，两个代理主机之间的往返时间为ping，为300毫秒(如预期)，因此我没有任何理由相信这是由于WAN仿真器引入了错误的模拟延迟而引起的，尽管有一些延迟为什么ping报告的RTT不能被信任的原因，我愿意尝试进一步探索。但是，在没有具体理由不信任广泛使用的ping实用程序的情况下，这似乎不是问题所在。 更新:我使用了先前编写并经过测试的网络流量工具，以确认TCP数据包以 1 x forward one-way WAN latency的一个方向传送，即使ActiveMQ TCP数据包需要进行额外的往返。我相信这进一步表明WAN仿真器没有引入这种行为。

我也没有任何理由相信延迟的任何有意义的部分都来自Camel，因为将WAN仿真器在两个方向上的延迟都设置为0ms时，我每秒可以推送约200条消息。我相信Camel不会在代理之间的网络接口上做任何事情(Camel只会通过发送ActiveMQ消息来访问该网络链接，而ActiveMQ Web控制台不会显示正在发送其他消息的证据)，但是在这里，如果有人知道有具体迹象表明 Camel 可能是这种情况，我愿意对此进行调查。

我最初的猜测是邮件正在重新传输，但是我看不到任何证据。当延迟增加三倍时，WAN模拟器上的吞吐量将下降到其原始值的1/3以上，而如果消息在代理之间重新传输，我希望它至少是原始值的2/3(1 /第一次传输为3，第二次传输为1/3，无论重传请求消息的大小如何，都加上少量。我还希望Web控制台上的出队计数大于入队计数，但这也没有发生。因此，我不相信这是怎么回事(即使是这样，也无法解释为什么某些延迟会发生这种情况，而其他情况不会发生，也无法解释为什么对于给定的延迟它不会发生然后突然开始发生) )。

是否有人对导致此行为的原因有任何想法，或者如果我必须阅读源代码以寻找线索，那么什至哪种ActiveMQ代码将是我的最佳起点？

Answer 1

事实证明，这纯粹是通过具有高带宽延迟产品的高延迟WAN调整TCP的问题。我们的经纪人到经纪人的连接是单工链接，而不是双工的(因此我们可以为两个经纪人使用相同的配置文件)，因此，在发送同步请求-响应消息时，一个链接始终处于空闲状态，而另一个链接正在使用中。

默认情况下，Linux会积极缩小空闲TCP连接的拥塞窗口(将每个RTT空闲状态的cwnd值减少一半)，这意味着TCP窗口将在发送每条消息时打开，然后缩小到initcwnd (= 3.2，在3.2之前的内核中)，等待通过其他TCP连接发送响应时。结果，拥塞窗口从未打开，因此我们一次只能传输几个数据包，这意味着我们必须为每个20KB消息等待一个额外的RTT(以及每个80KB额外的4-5个RTT)信息)。因此，根据观察到的消息大小，我观察到的3倍延迟纯粹是巧合，并且对于较大的消息，我观察到了不同的乘数。

https://serverfault.com/questions/386834/clarification-about-linux-tcp-window-size-and-delays描述了基本上相同的问题(尽管OP使用的消息非常小，并且某些答案锁存在该问题上，而不是TCP连接空闲状态；而是专注于OP自己接受的答案，而不是其他答案)以及解决方案:通过sysctl -w net.ipv4.tcp_slow_start_after_idle=0告诉内核在空闲期间不要更改拥塞窗口。

该问题还描述了我发现查看TCP套接字当前cwnd值的唯一方法:/usr/sbin/ss -i -t -e。 ss命令输出的文档非常缺乏(例如，我找不到能准确描述rcv_rtt含义的任何东西)，但是该实用程序本身对于确认我的拥塞窗口确实正在关闭非常有用。