高性能消息传递的关键因素与挑战

4星 · 超过85%的资源需积分: 4 93 浏览量更新于2024-08-01 收藏 556KB PDF 举报

"Topics_in_High-Performance_Messaging" 在高绩效消息传递系统领域，性能通常是设计决策中的关键因素。这里的“性能”可能指的是高消息速率、高负载数据传输速率、低延迟、高可扩展性和高效率，或者这些因素的组合。这类特性在金融市场数据、卫星遥测、军事指挥与控制等应用中至关重要。本书《高性能消息处理主题》由Robert A. Van Valzah、Todd L. Montgomery和Eric Bowden撰写，涵盖了多个关键议题，旨在提供高性能消息传递系统的深入理解。以下是一些主要内容的概述： 1. **TCP延迟** (TCPLatency)：讨论TCP协议在网络通信中的延迟问题，包括TCP握手和确认过程对性能的影响。 2. **组速率控制** (Group Rate Control)：探讨如何管理网络中的数据发送速率，以避免拥塞并保持性能。 3. **以太网流量控制** (Ethernet Flow Control)：讲解如何通过以太网协议来控制数据流，确保网络资源的有效利用。 4. **包丢失的误区** (Packet Loss Myths)：分析了包丢失对系统性能的误解，以及实际影响。 5. **监控消息系统** (Monitoring Messaging Systems)：强调了监测系统性能的重要性，以便及时发现和解决问题。 6. **UDP缓冲区背景** (UDP Buffering Background)：介绍UDP协议下的缓冲区管理和其对性能的影响。 7. **UDP缓冲区大小调整** (UDP Buffer Sizing)：提供了关于如何优化UDP缓冲区大小以提高性能的指导。 8. **多播回环** (Multicast Loopback)：讨论了多播数据包在本地环回时的处理方式。 9. **在多个接口上发送多播** (Sending Multicast on Multiple Interfaces)：探讨如何在不同网络接口上有效地发送多播数据。 10. **TTL=0保持多播本地** (TTL=0 to Keep Multicast Local)：解释了使用TTL（生存时间）值为0如何限制多播范围。 11. **TTL=1和Cisco CPU使用率** (TTL=1 and Cisco CPU Usage)：讨论了TTL值为1时对Cisco设备CPU的影响。 12. **间歇性网络多播丢失** (Intermittent Network Multicast Loss)：分析了不稳定的网络环境导致的多播数据丢失问题。 13. **多播地址分配** (Multicast Address Assignment)：讲述了多播地址的规划和分配策略。 14. **多播重传** (Multicast Retransmissions)：讨论了在数据丢失时多播数据的重新传输机制。 15. **消息延迟预算** (Messaging Latency Budget)：为系统设计者提供了考虑整体延迟预算的方法。 16. **延迟来源** (Sources of Latency)：详细解析了影响消息传递延迟的各种因素。 17. **中断合并的延迟** (Latency from Interrupt Coalescing)：介绍了中断合并如何影响系统延迟，并提供了优化建议。 18. **延迟测量概述** (Latency Measurement Overview)：概述了测量系统延迟的基本方法和技术。 19. **衡量CPU调度延迟** (Measuring CPU Scheduling Latency)：讨论了如何量化CPU调度过程中的延迟。 20. **衡量CPU竞争延迟** (Measuring CPU Contention Latency)：探讨了CPU资源竞争对系统性能的影响及度量。作者们通过多年的实践经验，总结了成功部署高性能消息系统所需的关键知识，旨在填补这一领域的知识空白。这本书对于从事高性能通信系统开发和优化的专业人士来说，是一份宝贵的参考资料。

Topics in High-Performance Messaging

withstand data loss. With two-party communication using TCP, it’s the only policy choice you have. However, group

communication with one sender and many receivers opens up all of the policy possibilities mentioned above.

Some messaging systems support only one policy and hence require no policy conﬁguration. Others may allow a

choice of policy. Any middle ground policy will need to be conﬁgured to establish the boundaries within which it

should operate.

The best results are obtained when the speciﬁc needs of a messaging application have been considered and the

messaging system has been conﬁgured to reﬂect them. A messaging system has no means to automatically select

from among the available group rate control policies. Human judgment is required.

3.5. Group Rate Control Recommendations

A group rate control policy should be chosen to match the needs of the application serving the group. The choice is

often made by weighing the beneﬁts of low latency against reliable delivery. These beneﬁts have to be considered for

individuals within the group and for the group as a whole.

In some applications, members of the group beneﬁt from the presence of other members. In these applications, the

group beneﬁt from reliable reception among all receivers may outweigh the pain of added latency or limited group

throughput. Consider a group of servers that share the load from a common set of clients. Assume that the servers

have to stay synchronized with a stream of messages to be able to answer client queries. If one server leaves the

group because it lost some messages, the clients it was serving would move to the remaining servers. This could lead

to a domino effect where a trafﬁc burst caused the slowest server to drop from the group which in turn increased the

load on the other servers causing them to fail in turn as well. Clearly in a situation like this, it’s better for the whole

group of servers to slow down a bit during a trafﬁc peak so that even the slowest among them can keep up without

loss. The appropriate group rate control policy for such an application is Extreme 1 (see Section 3.2.1).

Other applications see no incremental beneﬁt for the group if all members experience reliable reception. Consider a

group of independent traders who all subscribe to a market data stream. Traders who can keep up with the rate

convenient for the sender do not want the sender to slow down for those who can’t. Extreme 2 (see Section 3.2.2) is

probably the appropriate policy for an application like this. However, care must be taken to prevent the sender from

going faster than even the fastest trader as that often leads to NAK storms from which there is no recovery.

29West (http://www.29West.Com/) recommends a careful analysis of the policies that are best for the group using an

application and for individual members of the group. The rate control policy best suited to your application will

generally emerge from such an analysis. We have found that it is possible to build stable, low-latency messaging

systems with careful network design and a messaging layer like LBM (http://www.29West.Com/products/lbm/) that

supports a middle ground policy through the use of rate controls.

3.6. Group Rate Control and Transport Protocols

Once you’ve chosen a group rate control policy appropriate for your application, it’s important to chose a transport

protocol that can implement your chosen policy. Some transport protocols offer only the extreme policies while

others allow parameters to be set to implement a middle ground policy.

UDP provides no rate control at all, so it follows group policy Extreme 2 above (see Section 3.2.2).

TCP doesn’t operate naturally as a group communication protocol since it only supports unicast addressing.

However, when TCP is used to send copies of the same data stream to more than one receiver, all of the group rate

control issues discussed above are present. TCP’s inherent ﬂow control feature follows group policy Extreme 1

Topics in High-Performance Messaging

described above (see Section 3.2.1). If the sender is willing to use non-blocking I/O and manage buffering, then

Extreme 2 and middle ground policies can be implemented to some degree. For example LBM

(http://www.29West.Com/products/lbm/) supports middle ground policies over TCP with its latency-bounded TCP

feature.

Some reliable multicast transport protocols provide no rate control at all (e.g. TIBCO Rendezvous), some provide

only a ﬁxed maximum rate limit (e.g. PGM), and some provide separate rate controls for initial data transmission and

retransmission (e.g. LBT-RM from 29West (http://www.29West.Com/)). See Section 15 for details.

4. Ethernet Flow Control

In the process of testing the LBT-RM reliable multicast protocol used in the 29West (http://www.29West.Com/)

LBM (http://www.29West.Com/products/lbm/) messaging product, we noticed that some Ethernet switches and

NICs now implement a form of ﬂow control that can cause unexpected results. This is commonly seen in mixed

speed networks (e.g. 10/100 Mbps or 100/1000 Mbps). We have seen apparently strange results such as two

machines being able to send TCP at 100 Mbps but being limited to 10 Mbps for multicast using LBT-RM.

The cause of this seems to be Ethernet switches and NICs that implement the IEEE 802.3x Ethernet ﬂow control

standard. It seems to be most commonly implemented in desktop-grade switches. Infrastructure-grade equipment

makers seem to have identiﬁed the potential harm that Ethernet ﬂow control can cause and decided to implement it

carefully if at all (http://www.nwfusion.com/netresources/0913ﬂow2.html).

The intent of Ethernet ﬂow control is to prevent loss in switches by providing back pressure to the sending NIC on

ports that are going too fast to avoid loss. While this sounds like a good idea on the surface, higher-layer protocols

like TCP were designed to rely on loss as a signal that they should send more slowly. Hence, at the very least,

Ethernet ﬂow control duplicates the ﬂow control mechanism already built into TCP. At worst, it unnecessarily slows

senders when there’s no need.

Problems can happen with multicast on mixed-speed networks if a switch with Ethernet ﬂow control applies back

pressure on a multicast sender when it tries to go faster than the slowest active port on the switch. Consider the

scenario where two machines X and Y are connected to a switch at 100 Mbps while a third machine Z is connected

to the same switch at 10 Mbps. X can send TCP trafﬁc to Y at 100 Mbps since the switch sees no congestion

delivering data to Y’s switch port. But if X starts sending multicast, the switch tries to forward the multicast to Z’s

switch port as well as to Y’s. Since Z is limited to 10 Mbps, the switch senses congestion and prevents X from

sending faster than 10 Mbps.

We have tested switches that behave this way even if there are no multicast receivers on the slow ports. That is, these

switches did not have an IGMP snooping feature or an equivalent that would prevent multicast trafﬁc from being

forwarded out ports where there were no interested receivers. It seems best to avoid such switches when using

LBT-RM. Any production system with switches like this may be vulnerable to the problem where the network runs

ﬁne until one day somebody plugs an old laptop into a conference room jack and inadvertently limits all the

multicast sources to 10 Mbps.

It may also be possible to conﬁgure hosts to ignore ﬂow control signals from switches. For example, on Linux, the

/sbin/ethtool command may be able to conﬁgure a host to ignore pause signals that are sent from a switch

sensing congestion. Module conﬁguration parameters or registry settings might also be appropriate.

剩余35页未读，继续阅读

liujian135

粉丝: 0
资源: 8

高性能消息传递的关键因素与挑战

Packt.Mastering.IPython.4.0.2016

Manning JBoss in Action: Configuring the JBoss Application Server

《activmq in action 》

Kafka Message Queue Hands-On: From Beginner to Expert

Python Operations on MySQL Data: Revealing Real-world CRUD Tips

中国新能源汽车&充电桩（2018-2022）数据-最新出炉.zip

JDK17 win64位版本下载

【SCI一区】Matlab实现哈里斯鹰优化算法HHO-CNN-LSTM-Attention的风电功率预测算法研究.rar

Python 实现PSO-RBF和RBF粒子群优化算法优化径向基函数神经网络多输入单输出回归预测（含完整的程序和代码详解）

【SCI一区】Matlab实现斑马优化算法ZOA-CNN-LSTM-Attention的风电功率预测算法研究.rar

最新资源