On 07/28/2010 06:55 PM, Brian Crowell wrote:
On Wed, Jul 28, 2010 at 12:34 PM, Gordon Sim wrote:
What are your settings for the subscriber? Try batching (or not requiring)
acks. I wouldn't expect a single producer to be overwhelmingly faster than a
subscriber.
I'm using the Qpid C++ client AP
Hi Brian,
> On Wed, Jul 28, 2010 at 5:15 AM, Gordon Sim wrote:
> > Are you running the same test scenario as described in 3.3 of that
> > document? I.e. Simulating "60 AMQP clients talking to the
> AMQP broker
> > with 10 shared queues". (That is not what you get for perftest with
> > 'defaul
On Wed, Jul 28, 2010 at 12:50 PM, Jonathan Robie
wrote:
> Would a last value queue be helpful here?
Good suggestion, but no. I'm calculating VWAPs.
--Brian
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid
On Wed, Jul 28, 2010 at 12:34 PM, Gordon Sim wrote:
> What are your settings for the subscriber? Try batching (or not requiring)
> acks. I wouldn't expect a single producer to be overwhelmingly faster than a
> subscriber.
I'm using the Qpid C++ client API. My accept mode is explicit (so I
don't r
On 07/28/2010 01:28 PM, Brian Crowell wrote:
It sounds like I'm just going to have to create a more complicated
setup than I hoped for, trying to divide all the messages up into as
many queues as I can. I originally wanted all messages to go into a
few exchanges and let the subscriber bind to wh
On 07/28/2010 06:28 PM, Brian Crowell wrote:
On Wed, Jul 28, 2010 at 12:01 PM, Gordon Sim wrote:
If you have four connections pumping in messages to a queue as fast as they
can and only one pulling them out, then the queue will indeed backup.
The best part is that only one publisher is really
On Wed, Jul 28, 2010 at 12:01 PM, Gordon Sim wrote:
> If you have four connections pumping in messages to a queue as fast as they
> can and only one pulling them out, then the queue will indeed backup.
The best part is that only one publisher is really pushing as fast as
it can at any one time. O
On 07/28/2010 05:43 PM, Brian Crowell wrote:
On Wed, Jul 28, 2010 at 5:15 AM, Gordon Sim wrote:
Are you running the same test scenario as described in 3.3 of that document?
I.e. Simulating "60 AMQP clients talking to the AMQP broker with 10 shared
queues". (That is not what you get for perftest
On Wed, Jul 28, 2010 at 12:43 PM, Brian Crowell wrote:
> On Wed, Jul 28, 2010 at 5:15 AM, Gordon Sim wrote:
>> Are you running the same test scenario as described in 3.3 of that document?
>> I.e. Simulating "60 AMQP clients talking to the AMQP broker with 10 shared
>> queues". (That is not what y
On Wed, Jul 28, 2010 at 5:15 AM, Gordon Sim wrote:
> Are you running the same test scenario as described in 3.3 of that document?
> I.e. Simulating "60 AMQP clients talking to the AMQP broker with 10 shared
> queues". (That is not what you get for perftest with 'default settings'
> which is why I
On 07/27/2010 10:44 AM, Carl Trieloff wrote:
The boxes are then tuned according to the tuning guide, see
http://www.redhat.com/mrg/resources/
You're referring to the Realtime Tuning guide here?
Note that none of the test use the onboard NIC, onboard NIC's are
usually built
to save $ and neve
On 07/26/2010 09:18 PM, Brian Crowell wrote:
Red Hat claims to be able to get hundreds of thousands of messages
through on an eight core machine
(http://www.redhat.com/mrg/messaging/features/ or
http://www.redhat.com/f/pdf/mrg/Reference_Architecture_MRG_Messaging_Throughput.pdf).
I'm working with
ome cloud that supports
pay-per-use like Amazon? I would live to test this in an environment that I did
not have to tear down.
--- On Mon, 7/26/10, Donohue, Matt wrote:
From: Donohue, Matt
Subject: RE: QPID message throughput - Red Hat numbers
To: "Clark O'Brien", "use
n)
> 13523 21557 43122 10.5278
>
>
> -Original Message-
> From: Clark O'Brien [mailto:clark_obr...@yahoo.com]
>
> Sent: Monday, July 26, 2010 8:08 PM
> To: users@qpid.apache.org;
> Donohue, Matt; br...@fluggo.com
> Subject: Re: QPID message thro
5 and tcp-nodelay on)
13523 21557 43122 10.5278
-Original Message-
From: Clark O'Brien [mailto:clark_obr...@yahoo.com]
Sent: Monday, July 26, 2010 8:08 PM
To: users@qpid.apache.org; Donohue, Matt; br...@fluggo.com
Subject: Re: QPID message throughput - Red Hat numbers
A
, Ian.Kinkade wrote:
> From: Ian.Kinkade
> Subject: Re: QPID message throughput - Red Hat numbers
> To: users@qpid.apache.org, mdono...@structure-tech.com, br...@fluggo.com
> Date: Monday, July 26, 2010, 6:30 PM
> Hi Matt & Brian,
>
> It is my understanding that the Red Hat tests
Hi Matt & Brian,
It is my understanding that the Red Hat tests were conducted using a
Real-time Version of RHEL (MRG) and that it was specifically tuned for
MRG-M and its test applications.
You might want to try using the tuning application from the MRG install
before you run the tests.
I
The last project I worked on was the same for me. Not close to the MRG
throughput numbers with the same test and this was on an otherwise optimized
trading box.
The MRG qpid rpm was faster than an Intel C++ compiled version though.
Regards,
Matt
-Original Message-
From: Brian Crowell [m
18 matches
Mail list logo
