ASF subversion and git services commented on PROTON-508:

Commit 1565316 from r...@apache.org in branch 'proton/trunk'
[ https://svn.apache.org/r1565316 ]

PROTON-508: applied patch from Timothy Bish

> Use of Sasl auth results in a large performance hit.
> ----------------------------------------------------
>                 Key: PROTON-508
>                 URL: https://issues.apache.org/jira/browse/PROTON-508
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-j
>    Affects Versions: 0.6
>            Reporter: Timothy Bish
>             Fix For: 0.7
>         Attachments: PROTON-508.txt
> Using proton engine in ActiveMQ to implement AMQP 1.0 support we noticed that 
> a send from broker to the QPid JMS client is terribly slow for large 
> messages. 
> After some debugging it appears that the SaslImpl class imposes a pretty big 
> penalty due to the way it wraps the input and output processors of the 
> TransportImpl class. 
> When sasl() method of TransportImpl is called to get hold of the Sasl impl 
> for authentication the transport init method is called and buffers are 
> allocated.  In the SaslImpl class the result is that the output buffer is 
> allocated with the default value of the remote max frame size since there 
> hasn't been any negotiation yet.  After the SASL handshake completes and the 
> TransportImpl has updated itself to reflect the QPid client's preferred 64k 
> max frame size, the SaslImpl instance still continues on with it's internal 
> output buffer of 512 bytes.
> The end result of this is that as we attempt to send out a larger message we 
> end up in a situation where we are draining the underlying transport output 
> buffer 512 bytes at a time.
> I attached a patch that takes a stab at making the SaslImpl become a passive 
> entity after it completes the handshake.  In testing on ActiveMQ we go from 
> sending out a 10mb message in 35+ seconds to around 300ms.  Unfortunately 
> some of the tests in the proton tests suite are now failing with this so it's 
> not quite right.  

This message was sent by Atlassian JIRA

Reply via email to