13.2 优化消息生产者
13.2 Optimizing message producers
13.2 优化消息生产者
?
The rate at which producers send ?messages to an ActiveMQ message broker ?before
they’re dispatched to consumers is a fundamental element of overall application
performance. We’ll now cover some tuning parameters that affect the ?throughput
and latency of messages sent from a message producer to an ActiveMQ broker.
?
在代理分发消息到消息消费者之前,消息生产者发送消息到代理的效率是影响整个应用程序性能
的基本元素.下面我们将关注几个消息生产者发送消息给代理时,影响消息吞吐量和消息发送延迟
的调优参数.
?
13.2.1 Asynchronous send
13.2.1 异步发送
?
We’ve already covered ?the performance gains ?that can be ?achieved if you ?use
nonpersistent ?delivery ?for ?messages. In ?ActiveMQ ?nonpersistent ?delivery is
reliable, in that delivery of ?messages will survive network outages ?and system
crashes (as long as the producer is active—it holds messages for redelivery ?in
its failover transport cache). ?But you can also ?get the same performance ?gain
for persistent ?messages by ?setting the ?useAsyncSend property ?on the ?message
producer’s connection factory, as shown next.
?
我们已经了解了使用非持久化消息分发可以带来性能提升.ActiveMQ中非持久化消息分发是可靠的,
因为消息会在网络故障和系统崩溃(只要消息生产者依然是活动的--此时消息生产者将消息缓存在失效
转移连接器的缓存中)中幸存下来.但是,通过设置消息生产者的连接工厂的useAsyncSend属性,你仍然
可以在使用持久化消息时获得性能提升,请看下面示例代码:
?
Listing 13.8 Enabling asynchronous sends
代码清单13.8 启用异步发送
?
? ActiveMQConnectionFactory cf = new ActiveMQConnectionFactory();
? cf.setUseAsyncSend(true);
?
This will set a property that tells the MessageProducer not to expect a ?receipt
for messages it sends ?to the ActiveMQ broker. ?This means that a ?producer will
not wait until the message is on disk before sending another message.
?
上面代码将设置一个属性,告知消息生产者不要尝试从代理获取一个刚刚发送的消息的回执.
这就是说消息生产者在等待消息持久化到磁盘之后就不再等待(译注:消息回执)了而是继续
发送下一条消息.
?
If your application requires guaranteed delivery, it’s recommend that you use the
default delivery mode, persistent delivery, and preferably use transactions too.
?
如果你的程序要求消息精确分发,则推荐你使用系统默认的持久化消息分发模式,并且最好同时
使用事务.
?
The ?reasons for ?using asynchronous ?message delivery ?for gaining ?performance
should be ?well understood, ?and setting ?a property ?on the ActiveMQ connection
factory is a straightforward way of achieving that. Next we’ll cover a commonly
misunderstood ?feature in ?ActiveMQ: producer ?flow control. ?We see ?a lot ?of
questions ?about ?producers ?slowing down ?or ?pausing, ?and understanding ?flow
control will allow you to mitigate this situation in your applications.
?
使用异步方式发送消息获以取性能提升的原因不难理解,同时以这种方式实现性能提升的方式也
很简单--只要设置ActiveMQ连接工厂的一个属性即可.下一节将介绍ActiveMQ中一种通常不被
理解的特性:消息生产者流控制.我们将看到大量的关于消息生产者效率下降或暂停问题,并且理解
如何在你的应用程序中使用流控制来减少这些问题的发生.
?
?
13.2.2 Producer flow control
13.2.2 生产者流控制
?
Producer flow control ?allows the message ?broker to slow ?the rate of ?messages
that ?are passed ?through it ?when resources ?are running ?low. This ?typically
happens when ?consumers are ?slower than ?the producers, ?and messages are using
memory in the broker awaiting dispatch.
?
生产者流控制允许消息代理在系统资源紧张时降低消息的通过量.这种情况在消息消费者处理
速度慢于生产者时发生,此时消息会缓存在代理的内存中等待被发送.
?
A producer will wait until it receives a notification from the broker that it has space
for more messages, as shown in figure 13.3. Producer flow control is necessary to prevent
a broker’s usage limits for memory and temporary store space from being overrun,
especially for wide area networks.
?
消息生产者在收到代理通知有足够存储空间接收更多消息之前都会处于等待状态,如图13.3所示.
生产者流控制对于阻止代理的内存和临时存储空间超过限制的值来说是必要的,尤其是对于
广域网来说.
?
Producer flow control is enabled by default for persistent messages but must be
explicitly enabled for asynchronous publishing (persistent messages, or for connections
configured to always send asynchronously). You can enable flow control for asynchronous
publishing by setting the producerWindowSize property on the connection
factory.
?
对于持久化消息来说,生产者流控制默认时就是开启的,但是对于异步消息发布来说必须明确的指定
为开启(针对持久化消息,或对于配置成总是异步发送消息的连接来说).你可以通过设置连接工厂的
producerWindowSize属性来开启消息生产者异步发送消息的流控制.
?
Listing 13.9 Setting the producer window size
代码清单13.9 设置生产者窗口尺寸
?
? ActiveMQConnectionFactory cf = new ActiveMQConnectionFactory();
? cf.setProducerWindowSize(1024000);
?
The producerWindowSize property is used to specify the number of bytes allowed in
the producer’s send buffer before it’ll be forced to wait for a receipt from the broker
that it’s still within its usage limits. If this isn’t enabled for an asynchronous publisher,
the broker will still pause message flow, which defaults to blocking the message producer’s
transport. Blocking the transport will block all users of the connection, which
can lead to deadlock if the message consumers are sharing the connection. Producer
flow control allows blocking only the producer rather than the entire connection.
?
producerWindowSize属性用于设置生产者在收到代理的存储空间未超过限制值回执之前可以用来缓存消息的
字节大小,超过这个设置的值,生产者将等待代理回执(译注:而不再生产和发送消息).对于一个异步发送消息的生产
者来说,如果这个属性未开启,则代理仍然会暂停消息流动,这种情况下,默认会阻塞消息生产者的传输连接器.阻塞
传输连接器会阻塞所有使用该连接器连接的用户,如果消息消费者也使用同样的连接,则会导致死锁.生产者流控制
运行仅阻塞消息生产者而不是整个消息生产者使用的传输连接.
?
Although protecting the ?broker from running ?low on memory ?is a noble ?aim, it
doesn’t aid our cause for performance when everything slows down to the slowest
consumer! So let’s see what happens when you disable producer flow control, ?as
shown in bold in the following code. You can do this in the broker configuration
on a destination policy.
?
尽管保护代理不要运行在可用内存空间低的状态是一个不错的想法,但是这并不能改善
系统被最慢的消费者而拖慢时而产生的性能问题.所以,让我们看看禁用生产者流控制
时会发生什么,如厦门代码中的粗体字所示.你可以在代理的配置中配置消息目的地
策略来实现.
?
Listing 13.10 How to disable flow control
代码清单13.10 如何禁用流控制
?
<destinationPolicy>
? <policyMap>
? ? <policyEntries>
? ? ? <policyEntry?
? ? ? ? ? topic="FOO.>"
? ? ? ? ? producerFlowControl="false"
? ? ? ? ? memoryLimit="10mb" />
? ? </policyEntries>
? </policyMap>
</destinationPolicy>
?
With producer flow control disabled, messages for slow consumers will be off-lined to
temporary storage by default, enabling the producers and the rest of the consumers to
run at a much faster rate as outlined in figure 13.4. Additionally, the system usage
memory limit determines the point at which messages are offloaded to disk by the
pending message cursors. The system usage memory limit setting is applied across the
broker. This limit needs to be lower than the destination memory limits so that they
can kick in before producer flow control.
?
默认情况下,禁用了生产者流控制之后,发送给速度慢的消费者的消息会被存放到临时存储控件中,
以便消息生产者和其他消息消费者可以尽可能快的运行,如图13.4所示.另外,代理可用的最大内存
限制决定了在什么时候消息会通过追加到消息游标的形式持久化到磁盘上.系统可用最大内存
限制作用范围是整个代理.这个限制应该要低于消息目的地可用内存限制,以便在流控制之前起作用.
(译注:即,这个较小的值先起作用,则消息目的地使用内存不会超过配置的限制值,因为这个值较大)
?
Disabling producer flow control enables messaging applications to run at a pace
independent of the slowest consumer, though there’s a slight performance hit in offlining
messages. In an ideal world, consumers would always be running as fast as the
fastest producer, which neatly brings us to the next section on optimizing message
consumers.
?
尽管有一些因为存储消息而代理的性能损失,在禁用了生产者流控制之后,消息应用程序可以独立于最慢的
消息消费者而运行.在理想情况下,消息消费者总是与消息生产者一样快速运行,这就给我们引入下一节中关
于消息消费者的优化.
?
TUNING PRODUCER FLOW CONTROL
生产者流控制调优
?
By default, when producer flow control is enabled and there’s not enough space in
the broker for more messages, the producer’s send operation will block until space
becomes available on the broker. There are two ways to tune this parameter so that it
doesn’t block indefinitely and essentially hang the producer until space becomes
available.
?
默认情况下,当启用了生产者流控制后,当代理没有空间存放更多消息时,生产者发送消息的操作会被
阻塞知道代理有足够控件存储消息.有两中方式调整该参数,使得代理获取更多存储消息控件之前,消息
生产者不会无限期实质性的挂起.
?
The first tuning option for producer flow control is named sendFailIfNoSpace:
第一种调节消息生产者流控制的方式称为sendFailIfNoSpace
?
<systemUsage>
? <systemUsage sendFailIfNoSpace="true">
? ? <memoryUsage>
? ? ? <memoryUsage limit="128 mb"/>
? ? </memoryUsage>
? </systemUsage>
</systemUsage>
?
The sendFailIfNoSpace property puts control back into the hands of the producer by
throwing an exception on the client side when a send operation is attempted and space
isn’t available, instead of blocking the send operation indefinitely. This allows the producer
to catch the exception, wait a bit, and attempt the send the operation again.
?
sendFailIfNoSpace属性将控制权返还给消息生产者,在代理的消息存储已经不足而生产者仍然尝试发送操作时,
通过在生产者客户端抛出异常来代替永久性的阻塞生产者的发送操作.这就允许生产者可以捕捉这个异常,然后等待
一段时间后,继续尝试发送操作.
?
The second tuning option for producer flow control was made available in
ActiveMQ 5.4.1. This property is named sendFailIfNoSpaceAfterTimeout:
?
第二个调节生产者流控制的属性开始于ActiveMQ的5.4.1版本.该属性名称为
sendFailIfNoSpaceAfterTimeout:
?
<systemUsage>
? <systemUsage sendFailIfNoSpaceAfterTimeout="5000">
? ? <memoryUsage>
? ? ? <memoryUsage limit="128 mb"/>
? ? </memoryUsage>
? </systemUsage>
</systemUsage>
?
The sendFailIfNoSpaceAfterTimeout property provides a slightly different kind of
control. This property causes the send operation to fail with an exception on the client
side, but only after waiting the given amount of time for space to become available.
?
sendFailIfNoSpaceAfterTimeout与前面那个属性稍有不同. 配置了该属性后,在等待配置的时间后,如果代理端
依然没有足够的空间存储消息,则会在客户端客户端发送消息时抛出异常.
