You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2016/02/17 11:19:18 UTC
[jira] [Comment Edited] (QPID-7057) [Java Client] The performance
of the client connecting over TLS is significantly lower than before
[ https://issues.apache.org/jira/browse/QPID-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15150241#comment-15150241 ]
Keith Wall edited comment on QPID-7057 at 2/17/16 10:18 AM:
------------------------------------------------------------
(reposted comment)
The problem is that the Qpid is far more chatty than before with the SSLEngine. Now on the 0-8..0-91 ByteBufferSend#send is called at least three times per frame. When TLS is in use, this cause those buffers to be wrapped separately. Previously, AMQProtocolHandler first wrote the frames into a single reusable buffer, then passed the whole thing to ByteBufferSend#send meaning the engine is invoked once per frame.
I made a simple experimental change to test the effect of gathering the frame's constituent buffers and wrap in one go (using the SSLEngine.wrap(ByteByffer[]..) form). 0-9 performance is restored. 0-10 fails with an NPE on the Broker side. I don't understand why yet.
I ran a comparison:
* Java Broker trunk (6.1.0-SNAPSHOT) configured for TLSv1.0 only (-Dqpid.security.tls.protocolBlackList= -Dqpid.security.tls.protocolWhiteList=TLSv1)
* Client 6.0.0 vs 6.1.0.SNAPSHOT vs 6.1.0.SNAPSHOT + patch
* iMac i7 running Oracle Corporation version: 1.8.0_45-b14 OS : Mac OS X version: 10.10.5 arch: x86_64 cores: 8
* Test transient_autoack_ssl in hill climbing mode (20,000ms) over loop back
||protocol||0-9||0-10||
|6.0.0|45890|12052
6.1.0-SNAPSHOT|12899|12702|
6.1.0-SNAPSHOT + patch|45814|NPE|
{noformat}
#######################################################################
#
# Unhandled Exception java.lang.NullPointerException in Thread IO-/127.0.0.1:60049
#
# Exiting
#
########################################################################
java.lang.NullPointerException
at org.apache.qpid.server.protocol.v0_10.ServerAssembler.assemble(ServerAssembler.java:255)
at org.apache.qpid.server.protocol.v0_10.ServerAssembler.frame(ServerAssembler.java:151)
at org.apache.qpid.server.protocol.v0_10.ServerAssembler.received(ServerAssembler.java:79)
at org.apache.qpid.server.protocol.v0_10.ServerInputHandler.parse(ServerInputHandler.java:175)
at org.apache.qpid.server.protocol.v0_10.ServerInputHandler.received(ServerInputHandler.java:82)
at org.apache.qpid.server.protocol.v0_10.AMQPConnection_0_10$3.run(AMQPConnection_0_10.java:164)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.qpid.server.protocol.v0_10.AMQPConnection_0_10.received(AMQPConnection_0_10.java:156)
at org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:142)
at org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:559)
at org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:113)
at org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:452)
at org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:259)
at org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:108)
at org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:504)
at org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:337)
at org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:86)
at org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:462)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
was (Author: k-wall):
(reposted comment)
The problem is that the Qpid is far more chatty than before with the SSLEngine. Now on the 0-8..0-91 ByteBufferSend#send is called at least three times per frame. When TLS is in use, this cause those buffers to be wrapped separately. Previously, AMQProtocolHandler first wrote the frames into a single reusable buffer, then passed the whole thing to ByteBufferSend#send meaning the engine is invoked once per frame.
I made a simple experimental change to test the effect of gathering the frame's constituent buffers and wrap in one go (using the SSLEngine.wrap(ByteByffer[]..) form). 0-9 performance is restored. 0-10 fails with an NPE on the Broker side. I don't understand why yet.
I ran a comparison:
* Java Broker trunk (6.1.0-SNAPSHOT) configured for TLSv1.0 only (-Dqpid.security.tls.protocolBlackList= -Dqpid.security.tls.protocolWhiteList=TLSv1)
* Client 6.0.0 vs 6.1.0.SNAPSHOT vs 6.1.0.SNAPSHOT + patch
* iMac i7 running Oracle Corporation version: 1.8.0_45-b14 OS : Mac OS X version: 10.10.5 arch: x86_64 cores: 8
* Test transient_autoack_ssl in hill climbing mode (20,000ms) over loop back
||protocol||0-9||0-10||
|6.0.0|45890|12052
6.1.0-SNAPSHOT|12899|12702|
6.1.0-SNAPSHOT + patch|45814|NPE|
#######################################################################
#
# Unhandled Exception java.lang.NullPointerException in Thread IO-/127.0.0.1:60049
#
# Exiting
#
########################################################################
java.lang.NullPointerException
at org.apache.qpid.server.protocol.v0_10.ServerAssembler.assemble(ServerAssembler.java:255)
at org.apache.qpid.server.protocol.v0_10.ServerAssembler.frame(ServerAssembler.java:151)
at org.apache.qpid.server.protocol.v0_10.ServerAssembler.received(ServerAssembler.java:79)
at org.apache.qpid.server.protocol.v0_10.ServerInputHandler.parse(ServerInputHandler.java:175)
at org.apache.qpid.server.protocol.v0_10.ServerInputHandler.received(ServerInputHandler.java:82)
at org.apache.qpid.server.protocol.v0_10.AMQPConnection_0_10$3.run(AMQPConnection_0_10.java:164)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.qpid.server.protocol.v0_10.AMQPConnection_0_10.received(AMQPConnection_0_10.java:156)
at org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:142)
at org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:559)
at org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:113)
at org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:452)
at org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:259)
at org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:108)
at org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:504)
at org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:337)
at org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:86)
at org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:462)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
> [Java Client] The performance of the client connecting over TLS is significantly lower than before
> --------------------------------------------------------------------------------------------------
>
> Key: QPID-7057
> URL: https://issues.apache.org/jira/browse/QPID-7057
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: qpid-java-6.1
> Reporter: Alex Rudyy
> Fix For: qpid-java-6.1
>
> Attachments: SSLSender_experiment.patch, SSLSender_experiment_v2.patch
>
>
> The performance tests of current 6.1.x JMS client showed a significant degradation of performance with TLS transport (in ~7 times). For example, performances of test 'transient_autoack_ssl' with 6.1.x and 6.0.x clients using the same cipher suite TLS_ECDHE_RSA_WITH_AES_255_CBC_SHA384 in the same environment are as bellow:
> 4241 messages/second with 6.1.x client
> 32455 messages/second with 6.0.x client
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org