你在 Rabbit 中有一个队列。有一些客户端正在消费该队列。如果你完全没有设置 QoS 设置（basic.qos），那么 Rabbit 会尽快将队列中的所有消息推送到客户端，网络和客户端允许的范围内。消费者会在内存中膨胀，因为它们会将其自身 RAM 中的所有消息都缓存起来。如果你询问 Rabbit，队列可能显示为空，但可能有数百万条消息未确认，因为它们位于客户端中，准备由客户端应用程序进行处理。如果你添加一个新的消费者，队列中将没有消息发送给新的消费者。消息只是被缓冲在现有的客户端中，并且可能存在很长时间，即使有其他消费者可以更快地处理这些消息。这相当不理想。
因此，默认的 QoS prefetch 设置为客户端提供了无限的缓冲区，这可能导致不良的行为和性能。但是，你应该将 QoS prefetch 缓冲区大小设置为多少？目标是让消费者始终处于工作状态，但要最大程度地减少客户端的缓冲区大小，以便更多消息保留在 Rabbit 的队列中，从而可以用于新的消费者，或者在消费者空闲时发送给消费者。
欢迎回来！上次我们谈到了流量控制和延迟；今天让我们讨论一下不同的功能如何影响我们看到的性能。以下是一些简单的场景。和以前一样，它们都是一个发布者和一个消费者以尽可能快的速度发布消息的主题的变体。
所以今天我想谈谈 RabbitMQ 性能的一些方面。影响 RabbitMQ 服务器整体性能水平的变量数量非常多，今天我们将尝试调整其中的一些变量，看看我们能看到什么。
或者：如何在 WebSockets 或 SockJS 上正确进行多路复用
如你所知，WebSockets 是一项很酷的新 HTML5 技术，它允许你异步发送和接收消息。我们的兼容性层 - SockJS - 模拟它，即使在旧浏览器或代理后面也能工作。从概念上讲，WebSockets 非常简单。API 基本上是：连接、发送和接收。但是，如果你的 Web 应用程序有很多模块，并且每个模块都希望能够发送和接收数据，该怎么办？
AtomizeJS 是一个 JavaScript 库，用于编写在浏览器中运行的分布式程序，而无需在服务器上编写任何特定于应用程序的逻辑。
在 RabbitMQ 总部，我们花了很多时间争论。偶尔，我们会讨论一些重要的事情，比如消息传递的真正含义，以及可用于实现消息传递的不同 API 的范围。RabbitMQ 和 AMQP 提供了一个非常明确的消息传递接口：你确实有发送和接收这两个动词，你需要考虑你的消息传递模式是什么。在幕后有很多（通常非常巧妙的东西）发生，但尽管如此，接口还是相当低级和明确的，这提供了相当大的灵活性。但有时，这种类型的 API 并不是你尝试解决的问题的最自然选择 - 你是否真的遇到了僵局并认为“我这里需要一个 AMQP 消息代理”，或者你是否根据既有知识意识到你可以选择使用 AMQP 消息代理来解决你当前的问题？
我们想知道如何向更广泛的受众展示 SockJS 及其可能性。有一个可用的演示比解释枯燥的理论更有价值，但是如果你只是一个没有设计技能的无聊技术人员，你能展示什么？
对于这样的问题，打开一本历史书籍并回顾一下前几代没有艺术技能的计算机极客总是一个好主意。他们在做什么？在带有绿色字母的控制台上，他们玩着极客的电脑游戏，MUD（多人地下城）尤其受欢迎。
嘿，我们可以做到！
自从新的持久化存储出现在 RabbitMQ 2.0.0 中（是的，它现在已经不那么新了）以来，Rabbit 在应对不断增长、增长和增长的队列方面一直有一个相对良好的故事可以讲述，这些队列的大小使得它们无法保存在 RAM 中。Rabbit 很早就开始将消息写入磁盘，并继续以较慢的速度写入，因此当 RAM 变得非常紧张时，我们已经完成了大部分艰苦的工作，从而避免了突然的写入高峰。如果你的消息速率不是太高或不是太突发，那么这一切都应该不会对任何连接的客户端产生任何实际影响。
最近与客户的一些讨论让我们重新审视了我们认为已经解决的问题，并促使我们进行了一些更改。
