IBM Cloud Docs
队列管理器大小

队列管理器大小

了解可在 IBM Cloud 上部署的 IBM 队列管理器的特征。

轻量队列管理器

为了让您能够将 MQ 作为受管服务, IBM MQ on Cloud 服务提供了 Lite 队列管理器。 如果当前未部署轻量队列管理器,那么可以通过遵循创建队列管理器指南来创建轻量队列管理器。

注:

  • 每个轻量服务实例最多可以部署两个轻量队列管理器
  • 可以随时删除现有轻量队列管理器,并部署新的轻量队列管理器
  • 轻量队列管理器处于不活动状态 30 天后会被自动删除,但欢迎您部署新的轻量队列管理器
  • 如果已发送消息(使用非系统队列),或者已通过 IBM Cloud 用户界面登录到服务实例,那么轻量队列管理器会被视为处于活动状态
  • 轻量队列管理器可永远免费使用
  • 虽然所有计费队列管理器都执行了常规备份,但请注意, 执行 Lite 队列管理器的备份,因此用户配置不可恢复

计费队列管理器

IBM MQ on Cloud 服务提供以下可计费队列管理器大小:

  • 超小型:适合吞吐量要求适中的极轻或偶尔的工作负载

  • 小型:适合轻型工作负载,例如支持单个部门或应用程序

  • 中型:适合供多个轻型到中型工作负载应用程序共享使用

  • 大型:适合事务性能至关重要的高吞吐量场景

计费队列管理器根据其处于活动状态的虚拟处理器核心 (VPC) 小时数收费-例如,大大小队列管理器按小大小队列管理器速率的四倍 (4x) 收费。 每小时成本取决于您的本地货币,可以在 MQ 服务目录页面底部的 "定价计划" 中查看,您可以在其中选择您所在的国家或地区。

您可以在 "帐户" 或 "资源组" 级别的 IBM Cloud 使用情况仪表板 中查看可计费使用情况的详细信息。

如果在仪表板上看不到 MQ 使用情况,但已部署可计费队列管理器,请确保已选择查看资源组的使用情况,例如,在 "使用情况仪表板" 标题下的 Group: 下拉菜单中,选择 Resource Groups then default

队列管理器资源

下表提供了有关可用于每个队列管理器大小的资源的信息以及基于测试的性能结果的信息:

Lite[1] 超小 小型 大型
VPC
0.5 1 2 4
内存 (RAM GB)
1 1 2 4
磁盘大小 (GB)
20 20 40 40
磁盘性能(每秒 IO 操作数 - IOPS)
80 200 400 400
TCP 非持久消息吞吐量 [2] 每月 10000
**
800
每秒
1500
每秒
3000
每秒
6000
/秒
TCP 持久消息吞吐量 [3] 每月 10000
**
50
每秒
100
每秒
400
每秒
1000
/秒
REST 非持久消息吞吐量 [4] 每月 10000
**
250
/秒
450
每秒
900
每秒
1900
每秒
REST 持久消息吞吐量 [5] 每月 10000
**
50
每秒
100
每秒
400
每秒
1000
/秒
最大并发客户机连接数 [6] 20 30 50 300 1000

基准说明

  • 将缩放用于生成和使用消息的基准程序,以驱动给定队列管理器大小的最大并发连接数。 单线程或受限并行应用程序可能无法达到队列管理器的最大容量
  • 应用程序与队列管理器部署在同一云区域中,以便最大程度地缩短连接等待时间。 部署在不同云位置或本地数据中心的应用程序将导致吞吐量降低
  • 在 MQ 通道上配置了匿名 TLS (仅服务器) ,以便在消息数据和凭证流经网络时对其进行保护。 非 TLS 支持的通道通常具有大约 10% 的高吞吐量,但出于安全考虑,建议不要使用
  • 大小为 2KB 的消息用于基准程序方案。 对于合理的近似值, IBM MQ 吞吐量与消息大小具有反向线性相关性,因此 4KB 消息大小大约显示上述吞吐量的一半

TCP 基准

  • TCP 基准程序是使用 IBM MQ C 客户机 (每个应用程序线程使用一个客户机连接) 编写的。 请注意上面脚注 6 中有关 JMS 应用程序使用客户机连接的注释

REST 基准

  • REST 基准程序应用程序是使用 Python 客户机编写的,每个应用程序线程都使用基本认证来针对同一消息队列生成每个请求的新 TLS 连接。
  • 如果客户机应用程序使用 cookie 认证,那么 REST 消息吞吐量通常会高 10-15%。 请参阅 认证客户机以调用 REST API 请求

  1. 轻量队列管理器被分配有限的资源,不应用于性能评估。 ↩︎

  2. 性能估算高度依赖于特定的应用程序逻辑和拓扑。 建议用户在测试过程中验证自己的特定场景。 用于上表中数据的基准场景如下文分点所述。 ↩︎

  3. 性能估算高度依赖于特定的应用程序逻辑和拓扑。 建议用户在测试过程中验证自己的特定场景。 用于上表中数据的基准场景如下文分点所述。 ↩︎

  4. 性能估算高度依赖于特定的应用程序逻辑和拓扑。 建议用户在测试过程中验证自己的特定场景。 用于上表中数据的基准场景如下文分点所述。 ↩︎

  5. 性能估算高度依赖于特定的应用程序逻辑和拓扑。 建议用户在测试过程中验证自己的特定场景。 用于上表中数据的基准场景如下文分点所述。 ↩︎

  6. 用于 TCP 数字的 IBM MQ JMS 客户机库通常使用每个应用程序两个客户机连接 (一个用于 JMS 连接,一个用于每个 JMS 会话) ,因此连接限制 20 最多支持 10 个并发 JMS 应用程序。 ↩︎