Performance Degradation While Consuming Messages from Solace Queue via AMQP (Qpid JMS)

Solace Event Broker
1

Hi Team,

We are observing a significant performance degradation while consuming messages from Solace queues. Earlier, message consumption was very fast ( 5lakh message of each 10kb consumed in 3-4 minutes), but over the last few days the polling/consumption rate has dropped drastically.

We are using AMQP protocol with the Qpid JMS library, and there have been no client code changes on our side. Because of this sudden slowdown, we suspect there may be a network-level issue or broker-side issue affecting the throughput.

Could you please help us investigate the following:

Any recent changes or incidents on the Solace broker that could impact message delivery/consumption performance? Whether the AMQP connection from our client is showing latency, throttling, or flow-control issues on your side.Any queue-level metrics (back-pressure, spool usage, consumer flow control, etc.) that may explain the slowdown.

Recommendations on how we can further debug this from the client side.

Please let me know if you need connection details, queue names, or timestamps for the affected periods. I can provide them.

2

Hi there, I’m Solly AI, I generate responses to your questions using the power of the Solace Agent Mesh:

Please remember that AI technology can make mistakes so ensure that you read our Disclaimer.

AI Generated responses are a work in progress, your help in evaluating my response would be awesome! If my response makes sense, please mark it as a solution or give a :+1:. If my response doesn’t make sense for your topic, please react to it with a :shaking_face:.

Let me analyze the information about troubleshooting performance degradation when consuming messages from queues using AMQP protocol with Qpid JMS library on a software broker.

From the documentation, there are several key points to consider:

  1. Queue Type Considerations:
  • Non-exclusive queues with partitions are not supported for AMQP consumers
  • Non-exclusive queues without partitions (partition=0) can be used with multiple consumers for parallel processing
  • When using multiple consumers on a non-exclusive queue, message order is not guaranteed as messages are distributed in round-robin fashion
  1. Connection and Session Configuration:
  • Property name validation should be disabled on the connection factory using setValidatePropertyNames(false)
  • Each Message VPN requires its own unique AMQP port
  • The broker limits concurrent AMQP links at three levels:
    • Per session - 575 concurrent links
    • Per connection - Based on AMQP client profile configuration
    • Per broker - Based on broker limits
  1. Performance Considerations:
  • Using BytesMessage is recommended over TextMessage for optimal performance
  • The broker supports at-least-once delivery semantics
  • The broker will never offer a link-credit greater than 255 on a link for which it is the receiver

Therefore, to improve message consumption performance:

  1. Use a non-exclusive queue with 0 partitions to enable parallel processing with multiple consumers
  2. Configure appropriate connection and session settings
  3. Use BytesMessage format for optimal performance
  4. Consider the link-credit limitations when designing the consumption strategy

For specific configuration steps and commands, please refer to the Solace documentation.

Relevant sources:

3

I am using exclusive queue and single consumer.

4

Hi @sinchana, can you provide more details on the context here? Are you using a Solace Cloud broker or your own self-managed deployment of Solace?

If Solace Cloud, be aware also that any performance testing needs to use an appropriate service class of broker. If say you are using a Developer class instance, this will not be suitable as the underlying compute could use up burst credits in the beginning of the test to explain why high performance suddenly drops down.