中间件消息软件性能低下的影响因素
我计划将消息中间件集成到我的 Web 应用程序中。现在我正在测试不同的消息中间件软件，如 RabbitMQ、JMS、HornetQ 等。 该软件提供的示例可以运行，但没有给出预期的结果。
那么，我想知道哪些因素可以提高绩效，值得关注？
开发人员应该注意哪些方面来提高中间件消息传递软件的性能？
I am planning to inegrate messaging middleware in my web application. Right now I am tesing different messaging middleware software like RabbitMQ,JMS, HornetQ, etc..
Examples provided with this softwares are working but its not giving as desired results.
So, I want to know that which are the factors which are responsible to improve peformance that one should keep in eyes?
Which are the areas, a developer should take care of to improve the performance of middleware messaging software?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我是 HornetQ 的项目负责人，但我会尽力为您提供一个通用的答案，该答案可以应用于您选择的任何消息系统。
我看到的一个常见问题是人们问为什么单个生产者/单个消费者不会给你预期的性能。
当您发送消息并立即要求确认时，您需要等待：
同样，当您收到消息后，您向服务器确认：
如果您需要确认所有消息发送和消息确认，您可以需要等待这些步骤，因为您有涉及持久保存磁盘和在网络上发送位的硬件。
消息系统将尝试与许多生产者和许多消费者一起扩展。也就是说，如果许多人都在生产，他们都应该使用为所有消费者共享的服务器上可用的资源。
有多种方法可以加快单个生产者或单个消费者的速度：
其中一种是使用事务。因此，您可以最大限度地减少在磁盘上执行的块和同步，同时保留在服务器上并在网络上往返。 （这实际上在任何数据库上都是一样的）
另一种方法是使用回调而不是在消费者处阻塞。 （JMS 2 提出了类似于 HornetQ 上的ConfirmationHandler 的回调）。
另外：我认识的大多数提供商都会在其文档中包含性能部分，其中包含针对特定产品的要求和建议。您应该单独查看每个产品
I'm the project lead for HornetQ but I will try to give you a generic answer that could be applied to any message system you choose.
A common question that I see is people asking why a single producer / single consumer won't give you the expected performance.
When you send a message, and are asking confirmation right away, you need to wait:
Similarly when you are receiving a message, you ACK to the server:
And if you need confirmation for all your message-sends and mesage-acks you need to wait these steps as you have a hardware involved on persisting the disk and sending bits on the network.
Message Systems will try to scale up with many producers and many consumers. That is if many are producing they should all use the resources available at the server shared for all the consumers.
There are ways to speed up a single producer or single consumer:
One is by using transactions. So, you minimize the blocks and syncs you perform on disk while persisting at the server and roundtrips on the network. (This is actually the same on any database)
Another one, is by using Callbacks instead of blocking at the consumer. (JMS 2 is proposing a Callback similar to the ConfirmationHandler on HornetQ).
Also: most providers I know will have a performance section on their docs with requirements and suggestions for that specific product. You should look individually at each product