Using System Scaling Parameters

You can increase certain system scaling limits using system scaling parameters. You can specify system scaling parameters using configuration keys when you create a software broker instance (see Setting Scaling Parameters Using Configuration Keys). You can also change system scaling parameters while the software broker is running using the Solace CLI (see Setting Scaling Parameters for a Single Software Event Broker and Setting Scaling Parameters for an HA Group).

For details about the minimum system resources required, see System Resource Requirements.

To see the current values of the system scaling parameters, run the show system command in the Solace CLI, and look at the Scaling section of the output:

solace-vmr> show system
System Uptime:  0d 0h 24m 9s
Last Restart Reason:  User shutdown

Scaling:
    Max Connections: 1000
    Max Queue Messages: 100M
    Max Kafka Bridges: 10
    Max Kafka Broker Connections: 300

Topic Routing:
    Subscription Exceptions: Enabled
    Subscription Exceptions Defer: Enabled

You can configure the following system scaling parameters:

If you increase the value of these system scaling parameters, the event broker will require additional resources. For more information, see Additional System Resources, below.

Maximum Number of Client Connections

You can increase the number of concurrent client connections supported by the event broker using the max-connections system scaling parameter. By default, the broker is limited to 100 concurrent client connections, but it can be provisioned for up to 200,000 connections assuming that sufficient system resources are provided.

PubSub+ Broker Default Concurrent Client Connections Maximum Possible Concurrent Client Connections
PubSub+ Standard 100 1,000
PubSub+ Enterprise 100 200,000

The following functionality is not available on software event brokers configured for a maximum of 100 client connections:

To use these features, configure your software event brokers with a higher maximum number of client connections.

For PubSub+ Standard Edition, if you set the max-connections system scaling parameter higher than the maximum supported, the broker will fail to start.

The number of current client connections cannot be changed on a broker configured as a monitoring node in an HA group.

A number of related system limits (for example, the maximum number of client usernames and subscriptions) are automatically scaled to values appropriate for the permitted number of client connections; see the System Limits and Alerts spreadsheet (available from the Solace Products site for Appliance and PubSub+ Enterprise customers) for more information regarding those system limits.

The following types of clients use connections that count against the total number of max-connections:

  • Messaging clients (SMF, MQTT, AMQP, or REST): 1 connection each

  • Internal clients (VPN, VPN Bridge, Kafka Bridge Sender or Receiver, or DMR link per VPN): 1 connection each

Setting the Number of Concurrent Open Files for Container Images

To ensure reliable operation of the event broker, you must also increase the maximum number of concurrent open files per process when the maximum number of client connections is increased. The maximum number of concurrent open files for the container processes is governed by the nofiles resource limit. Most container runtimes support setting rlimit values using the ulimit parameter when creating a container. For example, in Docker Engine and Podman, for 10,000 client connections, add the --ulimit nofile=2448:72992 command line parameter when you create the container.

Resource Limit Maximum Client Connections
100 1,000 10,000 100,000 200,000
nofiles 2448:37392 2448:40992 2448:72992 2448:252992 2448:452992

For ease of use, and if the resources are available, we recommend using 2500:500000 for all instances.

Maximum Number of Queue Messages

You can increase the number of queue messages (references to messages queued for delivery to consumers) supported by the event broker using the max-queue-messages system scaling parameter. By default, the broker is limited to 100 million queue messages and can be provisioned up to 3 billion, provided sufficient system resources are provided.

PubSub+ Broker Default Maximum Queue Messages Maximum Possible Queue Messages
PubSub+ Standard 100,000,000 240,000,000
PubSub+ Enterprise 100,000,000 3,000,000,000

For PubSub+ Standard Edition, if you set the max-queue-messages system scaling parameter higher than the maximum supported, the broker will fail to start.

The maximum number of queue messages cannot be changed on a broker configured as a monitoring node in an HA group.

Maximum Number of Kafka Bridges

You can increase the number of Kafka bridges (Kafka senders + Kafka receivers) supported by the event broker using the max-kafka-bridges system scaling parameter. By default, the broker is limited to 0 bridges, but it can be provisioned for up to 200 bridges assuming that sufficient system resources are provided. In addition, keep in mind that you should not set the max-kafka-bridges value to greater than the max-connections value set for the system.

PubSub+ Broker Default Maximum Kafka Bridges Maximum Possible Kafka Bridges
PubSub+ Standard or Enterprise 0 200

The maximum number of Kafka bridges cannot be changed on a broker configured as a monitoring node in an HA group.

Maximum Number of Kafka Broker Connections

You can increase the number of concurrent Kafka broker connections supported by the event broker using the max-kafka-broker-connections system scaling parameter. By default, the broker is limited to 0 concurrent Kafka broker connections, but it can be provisioned for up to 10000 connections assuming that sufficient system resources are provided.

You can expect each Kafka sender and receiver to require approximately one connection from this budget for every Kafka broker in the Kafka cluster that they are configured to send messages to or receive messages from. If different senders and receivers connect to the same Kafka cluster these connections are all independent of one another and count separately against this limit. You should, in such cases, use a common sender or receiver with more queue or topic bindings to aid in scaling. The number of bindings does not affect the number of required connections.

When deciding on the maximum number of concurrent Kafka broker connections your deployment will support, you must ensure that enough process IDs (PIDs) are available to your platform. Kafka bridging requires that 1000 + the value you configure for max-kafka-broker-connections PIDs are available. For more information about setting per Node and per Pod PIDs limits in Kubernetes, see Process ID Limits And Reservations.

PubSub+ Broker Default Maximum Concurrent Kafka Broker Connections Maximum Possible Concurrent Kafka Broker Connections
PubSub+ Standard or Enterprise 0 10000

The maximum number of Kafka broker connections cannot be changed on a broker configured as a monitoring node in an HA group.

Additional System Resources

The resource requirements for the minimum (default) values of the system scaling parameters are listed in System Resource Requirements.

If you increase the value of any system scaling parameters, the event broker will require additional resources. To see how the system resource requirements change with higher values of system scaling parameters, use the System Resource Calculator.