Queue manager sizes - IBM Cloud

Learn about the characteristics of IBM® MQ queue managers available to deploy on IBM Cloud®.

Lite queue managers

To give you a taste of IBM MQ as a managed service, IBM MQ as a Service offers a Lite queue manager. If you do not currently have a Lite queue manager deployed, you can create one by following the Creating a queue manager guide.

You can deploy up to two Lite queue managers per Lite service instance
You can delete an existing Lite queue manager and deploy a new one at any time
Lite queue managers will automatically be deleted after 30 days of inactivity but you are welcome to deploy a new one.
A Lite queue manager is considered active if you have sent a message (using a non-SYSTEM queue), or have logged in to the service instance by using the IBM Cloud user interface.
You will never be charged for a Lite queue manager.
While all billable queue managers have regular backups taken, note that backups of Lite queue managers are not taken and therefore user configuration is non-recoverable.

Billable queue managers

IBM MQ as a Service offers the following billable queue manager sizes:

Extra Small: Appropriate for very light or occasional workloads with modest throughput requirements.
Small: Appropriate for light workloads such as supporting an individual department or application.
Medium: Appropriate for shared use by a number of light to moderate workload applications.
Large: Appropriate for heavy throughput scenarios where transaction performance is critical.

For reserved capacity deployments, billing is via capacity units instead of per queue manager. Queue managers can be created up to the purchased capacity. The available capacity that is required to create a queue manager depends on its size (see Queue manager resources). For other plans, a billable queue manager is charged based on the number of Virtual Processor Core (VPC) hours that it is active. For example, a Large size queue manager is charged at four times (4x) the rate of a Small size queue manager. The hourly cost is dependent on your local currency and can be seen in the Pricing Plan at the bottom of the MQ service catalog page, where you can select your country or region.

A billable queue manager is charged based on the number of Virtual Processor Core (VPC) hours that it is active, for example, a Large size queue manager is charged at four times (4x) the rate of a Small size queue manager. The hourly cost is dependent on your local currency and can be seen in the Pricing Plan at the bottom of the MQ service catalog page, where you can select your country or region.

You can see details of your billable usage in the IBM Cloud usage dashboard at the Account or Resource Group level.

Note: If you cannot see your IBM MQ usage on the dashboard, but have deployed a billable queue manager, ensure you have selected to view the usage for your resource group, for example. Under the Usage Dashboard title, in the Group: drop-down menu, select Resource Groups then default.

Queue manager resources

The following table provides information about the resources available to each queue manager size and performance results based on testing:

	Lite	Extra Small	Small	Medium	Large
VPC	-	0.5	1	2	4
Memory (RAM GB)	-	1	1	2	4
Disk Size (GB)	-	20	20	40	40
Disk performance (IO operations per second - IOPS)	-	80	200	400	400
TCP non-persistent message throughput	10000 per month	800 per second	1500 per second	3000 per second	6000 per second
TCP persistent message throughput	10000 per month	50 per second	100 per second	400 per second	1000 per second
REST non-persistent message throughput	10000 per month	250 per second	450 per second	900 per second	1900 per second
REST persistent message throughput	10000 per month	50 per second	100 per second	400 per second	1000 per second
Maximum concurrent client connections	20	30	50	300	1000

Benchmark notes

The benchmark applications for producing and consuming messages are scaled to drive the maximum concurrent number of connections for the given queue manager size. Single threaded or limited concurrency applications might not be able to reach the maximum capacity of the queue manager.
Applications are deployed in the same cloud region as the queue manager in order to minimize the latency of the connectivity. Applications deployed in different cloud locations or on-premises data centers will result in lower throughput.
Anonymous TLS (server-only) is configured on the IBM MQ channels in order to protect message data and credentials as they flow over the network. Non TLS-enabled channels typically have around 10% higher throughput but are not recommended for security reasons.
Messages of 2 KB size are used for the benchmark scenario. To a reasonable approximation IBM MQ throughput has an inverse linear correlation to the size of the message, so a 4 KB message size exhibits roughly half the throughput described above.

TCP benchmarks

The TCP benchmark applications are written using the IBM MQ C client, which uses one client connection per application thread. Please note the comment following the table, regarding the use of client connections by JMS applications.

REST benchmarks

The REST benchmark applications are written using a Python client with each application thread using basic authentication to generate a fresh TLS connection per request against the same message queue.
REST message throughput will generally be 10-15% higher if the client application uses cookie authentication. See Invoking the queue manager REST APIs.