[
https://issues.apache.org/jira/browse/QPID-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18126970#comment-18126970
]
Kato Kaito commented on QPID-8772:
----------------------------------
Hello, [~dakirily] ,
We're extensively testing Broker-J deployment in an environment with both
native AMQP clients (qpid-jms) and AMQP over WebSocket clients (rhea). Part of
the WebSockets clients are connected via VPN. Several scenarios like slow
clients or network issues have drawn our interest to the elevated CPU usage in
broker. For confirming the mechanism of the issue we used JFR and our internal
performance benchmark. I prepared a reduced version of a benchmark reproducing
the issue described in JIRA.
Here are out CPU measurements results:
||Protocol||Transport||Before||After||Reduction||
|AMQP 1-0|TCP|1005.03|0.01|~100%|
|AMQP 1-0|TLS|1010.18|10.41|~98.97%|
|AMQP 0-9-1|TCP|1004.99|3.9|~99.61%|
|AMQP 0-9-1|TLS|1002.26|1.30|~99.87%|
[^qpid-8772-jmh-main.zip]
Values are means in CPU milliseconds per elapsed second; 1000 ms/s is one
continuously occupied CPU core.
> [Broker-J] Excessive CPU usage from continuous rescheduling of blocked
> TCP/TLS writes
> -------------------------------------------------------------------------------------
>
> Key: QPID-8772
> URL: https://issues.apache.org/jira/browse/QPID-8772
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: qpid-java-broker-10.1.1
> Reporter: Kato Kaito
> Priority: Minor
> Attachments: qpid-8772-jmh-main.zip
>
>
> Deployments with many concurrent AMQP connections can experience write
> backpressure when some clients consume data slowly or communicate over
> constrained network paths, such as VPNs or TCP proxies. In these conditions,
> outbound data remains buffered while the broker waits for clients to receive
> it.
> The native TCP/TLS transport can repeatedly reschedule a connection with
> pending output without waiting for the socket to become writable. This causes
> repeated write attempts even when the connection cannot make progress. A
> stale partial-read indication can also keep a connection scheduled when
> subsequent processing skips reads.
> This behavior can consume significant CPU despite limited network throughput
> and occupy I/O workers needed by other connections. The impact is
> particularly relevant when several slow connections share an I/O pool with
> otherwise healthy clients.
> TLS requires an additional distinction: pending application output may be
> waiting for peer handshake data rather than socket write capacity. In this
> case, write readiness cannot advance the connection; the transport must allow
> reads and wait for incoming data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
