activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From magellings <mark.gelli...@qg.com>
Subject Re: NMS 1.1 and failover protocol slowness
Date Fri, 17 Apr 2009 22:18:42 GMT

I may have found a work around but I don't know the full implications of it.

Spring allows one to initialize synchronization.  Doing this along with
reusing a ConnectionFactory will cache the session in which you don't take
the hit of a connection attempt to the slave broker when each message is
sent.  If anyone knows any additional information about this Synchronization
Manager please let me know.

            TransactionSynchronizationManager.InitSynchronization();


            var connectionFactory = new ConnectionFactory(_uri);
                        connectionFactory.UserName = "frontend";
                        connectionFactory.Password = "pizz@";


magellings wrote:
> 
> I believe I figured out the performance problem.  Currently we are using
> JDBC master/slave.
> 
> The major performance problem is the socket connection is timing out on
> whichever tcp address in the failover address is slave.
> 
> Example:
> 
> private static Uri _uri = new
> Uri("failover:(tcp://localhost:10083,tcp://WAMQDEV1.qg.com:10083)?Randomize=false");
> 
> If "localhost" is running the slave broker, then it takes roughly 20-25s
> on each establishment of a session.  This is because the first connection
> attempt to "localhost" takes this long to timeout.  It then connects to
> "WAMQDEV1", the master, quickly.  If "localhost" is the master (the other
> way around) than performance is fine as "localhost" is tried first and a
> connection to "WAMQDEV1" is never attempted.
> 
> The problem is partially related to how the Spring NMS framework
> NmsTemplate connects as it establishes a new session on each message sent. 
> So the performance hit is taken on each message sent.  This isn't
> necessarily wrong though as we need to ensure we are sending to the master
> broker at the time of the message sending.
> 
> A second performance problem is the sheer fact that it takes roughly "1"
> second for each message sent now.  This is without utilizing the failover
> protocol functionality.  This is a pretty large performance hit compared
> to NMS version 1.0.  For example, now if 100 messages are sent the elapsed
> time is approximately 100 seconds.  I have yet to profile attempting to
> figure out why it is slower sending a message.
> 
> In regards to the failover protocol performance hit, if it is okay I will
> attempt to fix and will submit a patch.  I believe it should be as simple
> as tracking the successfully connected address and enhancing the logic to
> always try the address that previously connected successfully first.  If
> it fails than the successfully connected address is updated to the address
> of the new master broker and the process repeats.
> 
> 
> magellings wrote:
>> 
>> Hello.  Has anyone used the 1.1 binaries for NMS and NMS.ActiveMQ from
>> trunk and the failover: protocol?
>> 
>> I'm experiencing a lot of slowness and I've found at least one comment
>> (on item in issue tracker) stating the same.
>> 
>> http://issues.apache.org/activemq/browse/AMQNET-26?focusedCommentId=47183&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_47183

>> 
>> "Second, the recent changes to Apache.NMS.ActiveMQ's file
>> OpenWire/OpenWireFormat.cs create massive delays on my system. If I
>> revert that file back to the version 693666 (09-Sep-2008) then all my
>> code starts working without delays. It seems that the action of writing
>> to the bus (using Topics in my case) is delayed 120 seconds or so. Each
>> write seems to be delayed 15 seconds. Since startup involves several
>> writes the initialize the wire format, I suspect that a timeout variable
>> is set to 0 (zero) which does not allow a thread-swap to take place. So
>> it hangs. I will create a new issue for this problem.
>> 
>> Please test and give feedback. If it is positive, then Jim can commit the
>> change to the repository."
>> 
>> I've also noticed the Spring Messaging framework stalls when master and
>> slave brokers switch using the failover protocol.
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/NMS-1.1-and-failover-protocol-slowness-tp23028265p23107014.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message