Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-users@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of james.strachan@gmail.com
 designates 66.249.82.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Zg8WD4ITG/liOeqEMGAvT3C9HVCploaYVRN8v0Tecm02Ql1T2/qQI6q/zxisXyyAPA5zWKltiF5IHIJb3HGk9NVTtey2hqNSEE3gUwVrb9LvE1cXZwdVb8sHc7oH6IuF8nOc0RxGyg6Fhd4OX+U5CFl9T7v2dYQBWlGMPELoLTI=
Message-ID: <ec6e67fd0608250313n7d9b4967i5ef1ab1ab3eda547@mail.gmail.com>
Date: Fri, 25 Aug 2006 11:13:46 +0100
From: "James Strachan" <james.strachan@gmail.com>
To: activemq-users@geronimo.apache.org
Subject: Re: Bad AMQ Linux performance
In-Reply-To: <5980491.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <5966799.post@talk.nabble.com>
	 <ec6e67fd0608240911t4b534106jc31ad513fb7aa68@mail.gmail.com>
	 <5980491.post@talk.nabble.com>

The only thing I can think of is you're hitting the Nagler part of TCP
- the TCP_NODELAY setting.

I've just patched SVN HEAD to allow you to explicitly set/unset the
Socket.setTcpNoDelay() option. If you grab the latest source code
http://incubator.apache.org/activemq/source.html

then building it
http://incubator.apache.org/activemq/building.html

you should be able to try linux with these 2 URLs to see if it makes a
difference...

tcp://localhost:61616?tcpNoDelay=true
tcp://localhost:61616?tcpNoDelay=false

Let us know if thats it.


On 8/25/06, kaipa <alex.zaitsev@mtu-net.ru> wrote:
>
> Hi James,
>
> Thank you for reply. I still can not get it solved.
>
> 1. Yes, I send a number of messages to the queue first and then start to
> receive
> 2. If I disable persistence Linux is still that bad.
> 3. However, if I disable transactions -- everything works fine and fast both
> with/without persistence. So the problem is in how transactions are handled,
> I believe.
> 4. Broker is running on local file system.
>
> I have tried simpler test scenario: send-commit-receive-commit. On the same
> connection and session.
>
> Windows:
> Testing QService.sendMessage() followed by QService.receiveMessage()
> 1000 ops 1578ms
> Average speed: 633 ops/s
>
> Linux:
> Testing QService.sendMessage() followed by QService.receiveMessage()
> 1000 ops 202094ms
> Average speed: 4 ops/s
>
> I am absolutely lost!
>
> I have also tried to split message consumption into several threads and
> sessions -- that improves message consumption proportionally but this is not
> the root cause.
>
>
>
>
> James.Strachan wrote:
> >
> > BTW for the consumer tests, are there pleny of messages on the queue
> > before you start trying to consume? How does the performance differ
> > between linux and windows if you disable persistence?
> >
> > The only real difference between the two - assuming things are not
> > CPU, network or IO bound is the performance of the disk writes.
> > Persistent sending/consuming of messages by default requires blocking
> > the client until the broker does a sync-to-disk of the journal.
> >
> > Is the broker running on a local file system or a shared network drive?
> >
> > On 8/24/06, kaipa <alex.zaitsev@mtu-net.ru> wrote:
> >> Hi,
> >>
> >> I've read through archives and found that some people experience the same
> >> problem but there were no solution. Tests work great fast on Windows
> >> Laptop
> >> but unbarely slow on Linux server.
> >>
> >> - I have the standard configuration from Latest AMQ release (4.*). The
> >> only
> >> difference that I have tried Kaha persistence that works much faster than
> >> JDBCJournal. I tried JDBCJournal as well -- perfomance difference is the
> >> same.
> >> - I use tcp transport
> >> - Queue is persistent
> >> - Session is transactional
> >>
> >> First pair of tests commit session after every message. Second pair
> >> commit
> >> after all messages are sent or received. I am especially concerned about
> >> first pair that is too slow.
> >>
> >> Windows:
> >>
> >> Testing QService.sendMessage()
> >> 500 ops 453ms
> >> Average speed: 1103 ops/s
> >>
> >> Testing QService.consumeMessage()
> >> 500 ops 484ms
> >> Average speed: 1033 ops/s
> >>
> >> Testing QService.sendMessageNoCommit()
> >> 500 ops 188ms
> >> Average speed: 2659 ops/s
> >>
> >> Testing QService.consumeMessageNoCommit()
> >> 500 ops 125ms
> >> Average speed: 4000 ops/s
> >>
> >> Linux:
> >>
> >>      [java] Testing QService.sendMessage()
> >>      [java] 500 ops 22290ms
> >>      [java] Average speed: 22 ops/s
> >>
> >>      [java] Testing QService.consumeMessage()
> >>      [java] 500 ops 40366ms
> >>      [java] Average speed: 12 ops/s
> >>
> >>      [java] Testing QService.sendMessageNoCommit()
> >>      [java] 500 ops 926ms
> >>      [java] Average speed: 539 ops/s
> >>
> >>      [java] Testing QService.consumeMessageNoCommit()
> >>      [java] 500 ops 1017ms
> >>      [java] Average speed: 491 ops/s
> >>
> >> I suspect it is something with activemq io libraries. Java web services
> >> work
> >> fine on the same server, the problem is only with activemq.
> >>
> >> Please, advise where I can look into
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Bad-AMQ-Linux-performance-tf2159490.html#a5966799
> >> Sent from the ActiveMQ - User forum at Nabble.com.
> >>
> >>
> >
> >
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Bad-AMQ-Linux-performance-tf2159490.html#a5980491
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>


-- 

James
-------
http://radio.weblogs.com/0112098/