ZeroMQ 的可扩展性如何?

发布于 2025-01-05 20:06:49 字数 61 浏览 2 评论 0原文

ZeroMQ 的可扩展性如何?我特别有兴趣了解其在大量(10,000 - 15,000)个内核上运行的潜力。

How scalable is ZeroMQ? I'm especially interested in understanding its potential for running on a large number (10,000 - 15,000) of cores.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

哀由 2025-01-12 20:06:49

我们尝试使其尽可能具有可扩展性,但我个人仅在最多 16 个核心盒上进行了测试。直到这个极限,我们已经看到了几乎线性的缩放。

We've tried to make it as scalable as possible but I personally tested only on up to 16 core boxes. Up to that limit we've seen almost linear scaling.

云胡 2025-01-12 20:06:49

你没有提到你的 10k 或 15k 核心是否在同一个盒子上。

让我们假设它们是。理论上,每两年,一个盒子上的核心数量就会增加一倍。因此,如果我们现在有 16 核的盒子,那么 20 年后就会有 16K 核。

所以现在,您的问题可能是,“ZeroMQ 能否帮助我的应用程序扩展到如此庞大的内核数量,以便在未来 20 多年内实现扩展?”答案是“是的,但前提是你正确使用它”。这意味着使用 inproc 套接字和模式来设计您的应用程序,以正确划分工作和数据流。随着时间的推移,您将需要调整架构。

如果您的问题是“我可以在多个应用程序之间使用这么多内核来实现盈利吗”,那么答案更多地取决于您的操作系统而不是 ZeroMQ。您的 I/O 层可以处理负载吗?可能是的。

如果您的问题是“我可以在 10K-16K 盒子的云中使用 ZeroMQ”,那么答案是“是的,这已经在实践中得到了证明”。

You don't mention whether your 10k or 15k cores are on the same box or not.

Let's assume they are. Every two years the number of cores on a box can, theoretically, double. So if we have 16-core boxes today, it'll be 16K cores in 20 years.

So now, your question is maybe, "will ZeroMQ help my application scale to such huge numbers of cores, so that it will scale over the next 20+ years?" The answer is "yes, but only if you use it properly". This means designing your application using inproc sockets and patterns that properly divide the work, and flow of data. You will need to adjust the architecture over time.

If your question is, "can I profitably use that many cores between multiple applications", the answer lies with your O/S more than ZeroMQ. Can your I/O layer handle the load? Probably, yes.

And if your question is, "can I use ZeroMQ across a cloud of 10K-16K boxes", then the answer is "yes, this has already been proven in practice".

薯片软お妹 2025-01-12 20:06:49

请注意,尽管 ZeroMQ 内部是多线程的,但仅依靠它来将其扩展到大量内核可能并不明智。然而,由于 ZeroMQ 使用相同的 API 进行机器间、进程间和线程间通信,因此使用 ZeroMQ 编写应用程序很容易,该应用程序可以无缝转移到每个核心一个进程的场景或网格结构中。很多很多机器。

ZeroMQ 已经被誉为最快的结构化消息传递协议,因此如果您要进行基准测试来选择一项技术,ZeroMQ 绝对应该是其中之一。

使用 ZeroMQ 的两大原因是其易于使用的跨语言 API(请参阅 ZeroMQ 指南网站上的所有示例)以及其在线字节数和延迟方面的低开销。例如,ZeroMQ 可以利用 UDP 多播比任何 TCP 协议运行得更快,但应用程序程序员不需要学习新的 API。它全部包括在内。

Note that although ZeroMQ is multithreaded internally, it may not be wise to rely solely on that to scale it up to large numbers of cores. However, because ZeroMQ uses the same API for inter-machine, inter-process and inter-thread communication, it is easy to write application using ZeroMQ that can move seamlessly into a one-process-per-core scenario or into a grid fabric of many, many machines.

ZeroMQ already has a reputation for being the fastest structured messaging protocol around so if you were going to do benchmarks to choose a technology, ZeroMQ should definitely be one of them.

The two big reasons for using ZeroMQ are its easy-to-use cross-language API (see all the examples on the ZeroMQ Guide site) and its low overhead both in terms of bytes on the wire, and in terms of latency. For instance ZeroMQ can leverage UDP multicast to run faster than any TCP protocol, but the application programmer doesn't need to learn a new API. It is all included.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文