activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zao Liu" <>
Subject Re: Performance issue for ActiveMQ Server
Date Thu, 21 Feb 2008 22:09:49 GMT
Yeah, I do need to test for persistence, but firstly I wan to make sure the
is good. The result for consuming durable messages make me disappointed. Is
any specific
configuration for consuming durable messages?  I do test for producing and
durable messages at the same time, the throughput is also get more than
3500/s for consuming
messages. I don't think to consuming messages which has been saved to store
will be so slow,
only 50 msgs/s.

Zao Liu

On Thu, Feb 21, 2008 at 11:52 AM, Ben Chobot <> wrote:

> It sounds like you don't have a very firm grasp on what's going on,
> under the covers. If you need persistence, have you tried pulling the
> power cord from your server and verifying you haven't lost messages? If
> you don't care, why do you need persistence? :)
> I suspect that what might be happening is that your writes are going
> very fast because they're going into a write buffer somewhere along the
> line. Your reads are not going so fast, because what you're trying to
> read has left the buffer and now has to come off disk, and your disk
> isn't very fast.
> zaoliu wrote:
> > I have no idea about the IO systems. The server is using Linux Operating
> > System and has 6 cpus.  I find that the speed is getting lower and lower
> > with time. When produce 500000 messages, the speed is 3500/s. But when
> > consumer 700000 messages, the speed get down to avg 1700/s.  I think I
> need
> > to run the test for longer time to get a fair result. When consuming the
> > messages from the server, the speed is getting down much faster. Is 50
> msg/s
> > in normal condition?
> >
> >
> >
> > Ben Chobot wrote:
> >
> >> What is the underlying I/O system like for your broker? As I understand
> >> the persistence layer for ActiveMQ, 3,500 durable messages a second
> >> sounds too good to be true, assuming you're writing them safely.
> >>
> >>
> >>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message