You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Vavricka <va...@gmail.com> on 2017/11/09 15:10:02 UTC
Java Broker performance
Hi,
we are testing release candidate of Java Broker 7.0.0.
I checkout tag 7.0.0, build broker with tests without any problem.
We have sender and receiver based on proton 0.18.1.
Both sender and receiver are started at same time.
Sender is sending 1000 persistent messages to exchange and receiver expects
1000 messages in queue. Messages have size 1 kB.
We tried DERBY and BDB as persistent storage.
Sending and consuming of durable messages is slow (10 messages per second).
When sending non-persistent messages then broker behaves as expected.
Is there some settings that can optimize persistent storage?
Tomas
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Vavricka <va...@gmail.com>.
Hi,
when consumer is not attached sending of messages is slow too. We were
running performance tests for Java Broker 6.1.1 before 6 months and there
were no issues (throughput for 1K messages was around 10MB/s).
rgodfrey wrote
> Hi Tomas,
>
> are you saying that there is a significant degradation in performance
> between 7.0.0 and prior versions for this scenario, or do you see the same
> performance in 6.1.x?
>
> In terms of consuming - is the performance slow if you are consuming from
> a
> queue with 1000 messages already in it, or is the slowness just caused by
> the slow producer?
>
> Thanks,
> Rob
Code below is for JMS client 0.27.0 (without catching exceptions) which
behaves similarly as client based on proton 0.18.1.
Properties properties = new Properties();
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.qpid.jms.jndi.JmsInitialContextFactory");
properties.setProperty("connectionfactory.connection",
"amqp://localhost:20406?jms.username=C7&jms.password=C7");
properties.setProperty("topic.broadcastAddress", "broadcast");
InitialContext context = new InitialContext(properties);
Connection connection = ((ConnectionFactory)
context.lookup("connection")).createConnection();
Session session = connection.createSession(false,
Session.CLIENT_ACKNOWLEDGE);
MessageProducer broadcastProducer = session.createProducer((Destination)
context.lookup("broadcastAddress"));
connection.start();
char[] chars = new char[1024];
Arrays.fill(chars, 'f');
TextMessage message = session.createTextMessage(new String(chars));
message.setJMSDeliveryMode(DeliveryMode.PERSISTENT);
message.setJMSType("broadcast.C7_CashTransaction");
System.out.println(Instant.now());
int messageCount = 1000;
for (int i = 1 ; i <= messageCount ; i++)
{
broadcastProducer.send(message, DeliveryMode.PERSISTENT,
Message.DEFAULT_PRIORITY, Message.DEFAULT_TIME_TO_LIVE);
if (i % 100 == 0)
{
System.out.println(Instant.now() + " sent " + i + " messages");
}
}
System.out.println(Instant.now());
Output of client is below
[main] INFO com.deutscheboerse.amqp_1_0.examples.BroadcastSender - Creating
connection
[AmqpProvider :(1):[amqp://localhost:20406]] INFO
org.apache.qpid.jms.sasl.SaslMechanismFinder - Best match for SASL auth was:
SASL-SCRAM-SHA-256
[AmqpProvider :(1):[amqp://localhost:20406]] INFO
org.apache.qpid.jms.JmsConnection - Connection
ID:0333e24e-c00a-4dd7-91af-57fd1366512c:1 connected to remote Broker:
amqp://localhost:20406
2017-11-10T08:46:31.135Z
2017-11-10T08:46:41.770Z sent 100 messages
2017-11-10T08:46:52.449Z sent 200 messages
2017-11-10T08:47:03.958Z sent 300 messages
2017-11-10T08:47:15.174Z sent 400 messages
2017-11-10T08:47:25.514Z sent 500 messages
2017-11-10T08:47:36.045Z sent 600 messages
2017-11-10T08:47:46.432Z sent 700 messages
2017-11-10T08:47:57.797Z sent 800 messages
2017-11-10T08:48:09.434Z sent 900 messages
2017-11-10T08:48:20.419Z sent 1000 messages
2017-11-10T08:48:20.419Z
Keith Wall wrote
> Hi Tomas,
>
> That does sound surprising. These performance tests[1] are run, with
> BDB and using the latest Qpid JMS Client, against both the Broker-J
> 7.0.0 and 6.1.4 code lines each day, which is consistently showing
> v7.0.0 is faster for the five use-cases exercised by the tests (see
> perftests/etc/testdefs/defaultTests.js). I am interested to hear
> about your use-case. Do you have code you can share?
>
> cheers, Keith.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Vavricka <va...@gmail.com>.
It is ok for us to release 7.0.0 and implement this issue in 7.0.1.
Vast majority of our applications need this functionality.
Tomas
Keith Wall wrote
> The test is sending persistent messages so the broker is obliged to
> write them to disk. After the arrival of each message transfer, the
> Broker-J awaits the sync'd to disk (after the write) before sending
> the Disposition performative back to the client. The Qpid JMS Client
> is awaiting the Disposition, so it is only then that the
> MessageProducer#send returns and the application can send the next
> message. I infer that CPP Broker must be optimistically sending the
> Disposition back to the client before the data is sync'd, so that is
> why you see better performance (but with a lesser guarantee). If you
> were to switch the Qpid JMS Client to jms.forceAsyncSend[1], I would
> expect you would see greater performance. Let me ask a higher level
> question - what messaging guarantee does this application require?
>
> [1] https://qpid.apache.org/releases/qpid-jms-0.27.0/docs/index.html
>
> On 10 November 2017 at 15:50, Rob Godfrey <
> rob.j.godfrey@
> > wrote:
>> On 10 November 2017 at 16:39, Vavricka <
> vavricka.tomas@
> > wrote:
>>
>>> Hi,
>>>
>>> hardware:
>>> * Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
>>> * 16 GB RAM
>>> * HDD ST500DM002-1BD142
>>>
>>> timings:
>>> Currently Java Broker 6.1.1 seems to behave as version 7.0.0 RC. 10 - 30
>>> messages per second. Interesting is when I increase message size to
>>> 10kB.
>>> Messages per second are same but throughput is increased ten times.
>>> When I use nonpersistent messages everything goes smooth. Thousand of
>>> 1kB
>>> messages are sent within 1 second.
>>>
>>
>> So, this is more what I would expect (in the sense that 6.1 will behave
>> like 7.0 - the performance is unacceptable, but I think I understand it).
>>
>> I *think* the issue is that we have not yet implemented the optimisations
>> in the 1.0 layer for non-transactional durable messages to be processed
>> asynchronously. Because of this the rate of message processing is
>> dependent upon how many times fsync() can be called a second. 500/s is
>> probably about right for a SAN, ~20 is what I saw from conventional hard
>> drives; for SSDs with a battery backed write cache I've gotten > 1000/s.
>> Because it is dependent upon the number of fsyncs rather than the
>> throughput of the disk, increasing the message size will not affect the
>> rate and thus you will see a linear improvement in throughput.
>>
>> Fixing this shouldn't actually be a huge change, and after it you should
>> see something more like the C++ broker behaviour. Since this isn't (I
>> think) a regression between 7.0 and 6.1 I'd suggest that we progress with
>> the 7.0 release and then quickly follow that with a 7.0.1 that introduces
>> the necessary optimisation (we can essentially copy over the code from
>> the
>> 0-x protocol layers).
>>
>> -- Rob
>>
>>
>>>
>>> There are no extra JVM options, just the ones which are present in
>>> bin/qpid-server file.
>>>
>>> Heap and direct memory on broker is also default - -Xmx512m
>>> -XX:MaxDirectMemorySize=1536m. I tried to increase to four times larger
>>> ones
>>> -Xmx2048m -XX:MaxDirectMemorySize=6000m, but there was no change in
>>> messages
>>> per second.
>>>
>>> Unfortunately vmstat gives same values pro CPU, I am sending at least
>>> top
>>> output.
>>>
>>> 6.1.1:
>>> %Cpu(s): 6.9 us, 0.3 sy, 0.0 ni, 68.5 id, 24.1 wa, 0.0 hi, 0.2 si,
>>> 0.0
>>> st
>>>
>>> 7.0.0:
>>> %Cpu(s): 2.4 us, 0.4 sy, 0.0 ni, 71.2 id, 25.9 wa, 0.0 hi, 0.0 si,
>>> 0.0
>>> st
>>>
>>> When we tried on server where message store was stored on SAN disk,
>>> sending
>>> of messages increased to 500 msg/sec. With C++ broker on same machine we
>>> are
>>> able to send 5000 msg/sec.
>>>
>>> ps. I cannot create queue in 7.0.0 version by webgui when queue contains
>>> '.'
>>> character, in 6.1.1 version queue with dot in name can be created by
>>> webgui
>>>
>>>
>>> Keith Wall wrote
>>> > Hi Tomas,
>>> >
>>> > Nor can I reproduce any discernible difference in performance between
>>> > 6.1.1 and the 7.0.0 RC with your Java code. I have not tried the C++
>>> > yet.
>>> >
>>> > Can you share with us:
>>> >
>>> > * details of the hardware (including the storage) you are using for
>>> the
>>> > test.
>>> > * the timings you seeing for your tests for both the 6.1.1 case and
>>> 7.0.0
>>> > RC
>>> > * any extra JVM options you are passing either client or broker side.
>>> > * size of java heap (client side) and heap and direct memory (broker)
>>> >
>>> > Can I suggest that you collect vmstat type information for both runs
>>> > and compare? My expectation is that CPU usage, disk I/O, and network
>>> > utilisation should be approximately equal between the two runs.
>>> >
>>> > cheers, Keith
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
>>> f2158936.html
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
> users-unsubscribe@.apache
>>> For additional commands, e-mail:
> users-help@.apache
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@.apache
> For additional commands, e-mail:
> users-help@.apache
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Keith W <ke...@gmail.com>.
On 15 November 2017 at 14:13, Gordon Sim <gs...@redhat.com> wrote:
> On 10/11/17 18:11, Keith W wrote:
>>
>> I infer that CPP Broker must be optimistically sending the
>> Disposition back to the client before the data is sync'd, so that is
>> why you see better performance (but with a lesser guarantee).
>
>
> I don't believe that is the case. The c++ broker only sends back the
> disposition once confirmed by the store (and the linear store only confirms
> once synced).
>
Agreed. I retract my statement. I've now tested Tomas's JMS
reproduction against the C++ Broker with linearstore with durable
queue and Broker-J on the same hardware. I got similar throughput
numbers in both cases.
> Are you sure that (a) the store was in use and (b) you were waiting for
> acknowledgement of one message before sending the next (sending
> asynchronously is obviously faster)?
>
Tomas, can you tell us more?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Gordon Sim <gs...@redhat.com>.
On 10/11/17 18:11, Keith W wrote:
> I infer that CPP Broker must be optimistically sending the
> Disposition back to the client before the data is sync'd, so that is
> why you see better performance (but with a lesser guarantee).
I don't believe that is the case. The c++ broker only sends back the
disposition once confirmed by the store (and the linear store only
confirms once synced).
Are you sure that (a) the store was in use and (b) you were waiting for
acknowledgement of one message before sending the next (sending
asynchronously is obviously faster)?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Keith W <ke...@gmail.com>.
The test is sending persistent messages so the broker is obliged to
write them to disk. After the arrival of each message transfer, the
Broker-J awaits the sync'd to disk (after the write) before sending
the Disposition performative back to the client. The Qpid JMS Client
is awaiting the Disposition, so it is only then that the
MessageProducer#send returns and the application can send the next
message. I infer that CPP Broker must be optimistically sending the
Disposition back to the client before the data is sync'd, so that is
why you see better performance (but with a lesser guarantee). If you
were to switch the Qpid JMS Client to jms.forceAsyncSend[1], I would
expect you would see greater performance. Let me ask a higher level
question - what messaging guarantee does this application require?
[1] https://qpid.apache.org/releases/qpid-jms-0.27.0/docs/index.html
On 10 November 2017 at 15:50, Rob Godfrey <ro...@gmail.com> wrote:
> On 10 November 2017 at 16:39, Vavricka <va...@gmail.com> wrote:
>
>> Hi,
>>
>> hardware:
>> * Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
>> * 16 GB RAM
>> * HDD ST500DM002-1BD142
>>
>> timings:
>> Currently Java Broker 6.1.1 seems to behave as version 7.0.0 RC. 10 - 30
>> messages per second. Interesting is when I increase message size to 10kB.
>> Messages per second are same but throughput is increased ten times.
>> When I use nonpersistent messages everything goes smooth. Thousand of 1kB
>> messages are sent within 1 second.
>>
>
> So, this is more what I would expect (in the sense that 6.1 will behave
> like 7.0 - the performance is unacceptable, but I think I understand it).
>
> I *think* the issue is that we have not yet implemented the optimisations
> in the 1.0 layer for non-transactional durable messages to be processed
> asynchronously. Because of this the rate of message processing is
> dependent upon how many times fsync() can be called a second. 500/s is
> probably about right for a SAN, ~20 is what I saw from conventional hard
> drives; for SSDs with a battery backed write cache I've gotten > 1000/s.
> Because it is dependent upon the number of fsyncs rather than the
> throughput of the disk, increasing the message size will not affect the
> rate and thus you will see a linear improvement in throughput.
>
> Fixing this shouldn't actually be a huge change, and after it you should
> see something more like the C++ broker behaviour. Since this isn't (I
> think) a regression between 7.0 and 6.1 I'd suggest that we progress with
> the 7.0 release and then quickly follow that with a 7.0.1 that introduces
> the necessary optimisation (we can essentially copy over the code from the
> 0-x protocol layers).
>
> -- Rob
>
>
>>
>> There are no extra JVM options, just the ones which are present in
>> bin/qpid-server file.
>>
>> Heap and direct memory on broker is also default - -Xmx512m
>> -XX:MaxDirectMemorySize=1536m. I tried to increase to four times larger
>> ones
>> -Xmx2048m -XX:MaxDirectMemorySize=6000m, but there was no change in
>> messages
>> per second.
>>
>> Unfortunately vmstat gives same values pro CPU, I am sending at least top
>> output.
>>
>> 6.1.1:
>> %Cpu(s): 6.9 us, 0.3 sy, 0.0 ni, 68.5 id, 24.1 wa, 0.0 hi, 0.2 si,
>> 0.0
>> st
>>
>> 7.0.0:
>> %Cpu(s): 2.4 us, 0.4 sy, 0.0 ni, 71.2 id, 25.9 wa, 0.0 hi, 0.0 si,
>> 0.0
>> st
>>
>> When we tried on server where message store was stored on SAN disk, sending
>> of messages increased to 500 msg/sec. With C++ broker on same machine we
>> are
>> able to send 5000 msg/sec.
>>
>> ps. I cannot create queue in 7.0.0 version by webgui when queue contains
>> '.'
>> character, in 6.1.1 version queue with dot in name can be created by webgui
>>
>>
>> Keith Wall wrote
>> > Hi Tomas,
>> >
>> > Nor can I reproduce any discernible difference in performance between
>> > 6.1.1 and the 7.0.0 RC with your Java code. I have not tried the C++
>> > yet.
>> >
>> > Can you share with us:
>> >
>> > * details of the hardware (including the storage) you are using for the
>> > test.
>> > * the timings you seeing for your tests for both the 6.1.1 case and 7.0.0
>> > RC
>> > * any extra JVM options you are passing either client or broker side.
>> > * size of java heap (client side) and heap and direct memory (broker)
>> >
>> > Can I suggest that you collect vmstat type information for both runs
>> > and compare? My expectation is that CPU usage, disk I/O, and network
>> > utilisation should be approximately equal between the two runs.
>> >
>> > cheers, Keith
>>
>>
>>
>>
>>
>> --
>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
>> f2158936.html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Rob Godfrey <ro...@gmail.com>.
On 10 November 2017 at 16:39, Vavricka <va...@gmail.com> wrote:
> Hi,
>
> hardware:
> * Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
> * 16 GB RAM
> * HDD ST500DM002-1BD142
>
> timings:
> Currently Java Broker 6.1.1 seems to behave as version 7.0.0 RC. 10 - 30
> messages per second. Interesting is when I increase message size to 10kB.
> Messages per second are same but throughput is increased ten times.
> When I use nonpersistent messages everything goes smooth. Thousand of 1kB
> messages are sent within 1 second.
>
So, this is more what I would expect (in the sense that 6.1 will behave
like 7.0 - the performance is unacceptable, but I think I understand it).
I *think* the issue is that we have not yet implemented the optimisations
in the 1.0 layer for non-transactional durable messages to be processed
asynchronously. Because of this the rate of message processing is
dependent upon how many times fsync() can be called a second. 500/s is
probably about right for a SAN, ~20 is what I saw from conventional hard
drives; for SSDs with a battery backed write cache I've gotten > 1000/s.
Because it is dependent upon the number of fsyncs rather than the
throughput of the disk, increasing the message size will not affect the
rate and thus you will see a linear improvement in throughput.
Fixing this shouldn't actually be a huge change, and after it you should
see something more like the C++ broker behaviour. Since this isn't (I
think) a regression between 7.0 and 6.1 I'd suggest that we progress with
the 7.0 release and then quickly follow that with a 7.0.1 that introduces
the necessary optimisation (we can essentially copy over the code from the
0-x protocol layers).
-- Rob
>
> There are no extra JVM options, just the ones which are present in
> bin/qpid-server file.
>
> Heap and direct memory on broker is also default - -Xmx512m
> -XX:MaxDirectMemorySize=1536m. I tried to increase to four times larger
> ones
> -Xmx2048m -XX:MaxDirectMemorySize=6000m, but there was no change in
> messages
> per second.
>
> Unfortunately vmstat gives same values pro CPU, I am sending at least top
> output.
>
> 6.1.1:
> %Cpu(s): 6.9 us, 0.3 sy, 0.0 ni, 68.5 id, 24.1 wa, 0.0 hi, 0.2 si,
> 0.0
> st
>
> 7.0.0:
> %Cpu(s): 2.4 us, 0.4 sy, 0.0 ni, 71.2 id, 25.9 wa, 0.0 hi, 0.0 si,
> 0.0
> st
>
> When we tried on server where message store was stored on SAN disk, sending
> of messages increased to 500 msg/sec. With C++ broker on same machine we
> are
> able to send 5000 msg/sec.
>
> ps. I cannot create queue in 7.0.0 version by webgui when queue contains
> '.'
> character, in 6.1.1 version queue with dot in name can be created by webgui
>
>
> Keith Wall wrote
> > Hi Tomas,
> >
> > Nor can I reproduce any discernible difference in performance between
> > 6.1.1 and the 7.0.0 RC with your Java code. I have not tried the C++
> > yet.
> >
> > Can you share with us:
> >
> > * details of the hardware (including the storage) you are using for the
> > test.
> > * the timings you seeing for your tests for both the 6.1.1 case and 7.0.0
> > RC
> > * any extra JVM options you are passing either client or broker side.
> > * size of java heap (client side) and heap and direct memory (broker)
> >
> > Can I suggest that you collect vmstat type information for both runs
> > and compare? My expectation is that CPU usage, disk I/O, and network
> > utilisation should be approximately equal between the two runs.
> >
> > cheers, Keith
>
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
> f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Java Broker performance
Posted by Oleksandr Rudyy <or...@gmail.com>.
Hi Tomas,
Thanks for feedback. I will merge the changes into 7.0.1.
We will be looking into performance improvements for AMQP 1.0 later
this year. Though, we do not have a date exactly when we will be doing
this work.
The changes we had implemented are tactical. They are small enough to
be ported into 7.0.x branch.
For the use cases exercised by your sample applications I cannot think
about any Broker settings which would improve the performance farther.
Hopefully the following work will increase the performance and resolve
the Broker-J lagging behind the C++ broker.
Kind Regards,
Alex
On 29 January 2018 at 09:40, Tomas Soltys <to...@gmail.com> wrote:
> Hi Alex,
>
> The performance is way much better now and is acceptable for us. Thank you
> very much for your effort.
>
> Do you know why the performance is still lagging behind the C++ broker? Is
> it something that can be influenced by the broker settings?
>
> Thanks and regards,
> Tomas
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Tomas Soltys <to...@gmail.com>.
Hi Alex,
The performance is way much better now and is acceptable for us. Thank you
very much for your effort.
Do you know why the performance is still lagging behind the C++ broker? Is
it something that can be influenced by the broker settings?
Thanks and regards,
Tomas
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Oleksandr Rudyy <or...@gmail.com>.
Hi Tomas,
We are going to port the implemented changes into 7.0.x branch for
inclusion into 7.0.1.
Please, let us know whether the sending and receiving performances are
acceptable for you.
Kind Regards,
Alex
On 23 January 2018 at 15:59, Oleksandr Rudyy <or...@gmail.com> wrote:
> Hi Tomas,
>
> Today I committed changes [1] into master improving the performance of
> the broker-j for the Receiver use case. The commit is made against
> QPID-8032.
>
> I tested the changes locally on my machine and could see the
> improvements in broker-j performance. Before the change the dequeue
> operations in broker-j on my test machine were 7-8 times slower than
> the ones in cpp broker.
> After the change the performance has increased but the broker-j is
> still 2-3 times slower than cpp broker.
>
> Please give it a try on your environment and let us know about your
> performance results.
>
> Kind Regards,
> Alex
>
>
> [1] https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=a1ed997
>
> On 22 January 2018 at 16:44, Oleksandr Rudyy <or...@gmail.com> wrote:
>> Hi Tomas,
>>
>> We are currently looking into performance improvements for the Receiver.
>> We will notify you after necessary changes are made and ready for testing.
>>
>> Kind Regards,
>> Alex
>>
>>
>>
>> On 22 January 2018 at 11:20, Tomas Soltys <to...@gmail.com> wrote:
>>> Hi Keith,
>>>
>>> I can confirm that sending is now much faster.
>>>
>>> *C++ broker*
>>> $ ./Broadcaster 20001
>>> real 0m0.085s
>>> user 0m0.027s
>>> sys 0m0.005s
>>>
>>> *Java broker*
>>> $ ./Broadcaster 20002
>>> real 0m0.876s
>>> user 0m0.037s
>>> sys 0m0.011s
>>>
>>> However receiving is still much slower.
>>>
>>> *C++ broker*
>>> $ time ./Receiver 20001
>>> real 0m0.113s
>>> user 0m0.035s
>>> sys 0m0.014s
>>>
>>> *Java broker*
>>> $ time ./Receiver 20002
>>> real 0m50.168s
>>> user 0m0.061s
>>> sys 0m0.032s
>>>
>>> See attached file cpp_vs_java.gz
>>> <http://qpid.2158936.n2.nabble.com/file/t365522/cpp_vs_java.gz> which
>>> contains:
>>> Broadcaster.cpp and Receiver.cpp based on qpid-proton 0.19.0
>>> Setup for C++ broker 1.37.0
>>> Setup for Java broker (master from 22-nd January 2017)
>>>
>>> Regards,
>>> Tomas
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Oleksandr Rudyy <or...@gmail.com>.
Hi Tomas,
Today I committed changes [1] into master improving the performance of
the broker-j for the Receiver use case. The commit is made against
QPID-8032.
I tested the changes locally on my machine and could see the
improvements in broker-j performance. Before the change the dequeue
operations in broker-j on my test machine were 7-8 times slower than
the ones in cpp broker.
After the change the performance has increased but the broker-j is
still 2-3 times slower than cpp broker.
Please give it a try on your environment and let us know about your
performance results.
Kind Regards,
Alex
[1] https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=a1ed997
On 22 January 2018 at 16:44, Oleksandr Rudyy <or...@gmail.com> wrote:
> Hi Tomas,
>
> We are currently looking into performance improvements for the Receiver.
> We will notify you after necessary changes are made and ready for testing.
>
> Kind Regards,
> Alex
>
>
>
> On 22 January 2018 at 11:20, Tomas Soltys <to...@gmail.com> wrote:
>> Hi Keith,
>>
>> I can confirm that sending is now much faster.
>>
>> *C++ broker*
>> $ ./Broadcaster 20001
>> real 0m0.085s
>> user 0m0.027s
>> sys 0m0.005s
>>
>> *Java broker*
>> $ ./Broadcaster 20002
>> real 0m0.876s
>> user 0m0.037s
>> sys 0m0.011s
>>
>> However receiving is still much slower.
>>
>> *C++ broker*
>> $ time ./Receiver 20001
>> real 0m0.113s
>> user 0m0.035s
>> sys 0m0.014s
>>
>> *Java broker*
>> $ time ./Receiver 20002
>> real 0m50.168s
>> user 0m0.061s
>> sys 0m0.032s
>>
>> See attached file cpp_vs_java.gz
>> <http://qpid.2158936.n2.nabble.com/file/t365522/cpp_vs_java.gz> which
>> contains:
>> Broadcaster.cpp and Receiver.cpp based on qpid-proton 0.19.0
>> Setup for C++ broker 1.37.0
>> Setup for Java broker (master from 22-nd January 2017)
>>
>> Regards,
>> Tomas
>>
>>
>>
>>
>> --
>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Oleksandr Rudyy <or...@gmail.com>.
Hi Tomas,
We are currently looking into performance improvements for the Receiver.
We will notify you after necessary changes are made and ready for testing.
Kind Regards,
Alex
On 22 January 2018 at 11:20, Tomas Soltys <to...@gmail.com> wrote:
> Hi Keith,
>
> I can confirm that sending is now much faster.
>
> *C++ broker*
> $ ./Broadcaster 20001
> real 0m0.085s
> user 0m0.027s
> sys 0m0.005s
>
> *Java broker*
> $ ./Broadcaster 20002
> real 0m0.876s
> user 0m0.037s
> sys 0m0.011s
>
> However receiving is still much slower.
>
> *C++ broker*
> $ time ./Receiver 20001
> real 0m0.113s
> user 0m0.035s
> sys 0m0.014s
>
> *Java broker*
> $ time ./Receiver 20002
> real 0m50.168s
> user 0m0.061s
> sys 0m0.032s
>
> See attached file cpp_vs_java.gz
> <http://qpid.2158936.n2.nabble.com/file/t365522/cpp_vs_java.gz> which
> contains:
> Broadcaster.cpp and Receiver.cpp based on qpid-proton 0.19.0
> Setup for C++ broker 1.37.0
> Setup for Java broker (master from 22-nd January 2017)
>
> Regards,
> Tomas
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Tomas Soltys <to...@gmail.com>.
Hi Keith,
I can confirm that sending is now much faster.
*C++ broker*
$ ./Broadcaster 20001
real 0m0.085s
user 0m0.027s
sys 0m0.005s
*Java broker*
$ ./Broadcaster 20002
real 0m0.876s
user 0m0.037s
sys 0m0.011s
However receiving is still much slower.
*C++ broker*
$ time ./Receiver 20001
real 0m0.113s
user 0m0.035s
sys 0m0.014s
*Java broker*
$ time ./Receiver 20002
real 0m50.168s
user 0m0.061s
sys 0m0.032s
See attached file cpp_vs_java.gz
<http://qpid.2158936.n2.nabble.com/file/t365522/cpp_vs_java.gz> which
contains:
Broadcaster.cpp and Receiver.cpp based on qpid-proton 0.19.0
Setup for C++ broker 1.37.0
Setup for Java broker (master from 22-nd January 2017)
Regards,
Tomas
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Keith W <ke...@gmail.com>.
Hi Tomas,
The work for QPID-8032 is done on master. If you could repeat your
test-case with Broker-J compiled for master and let us know how
performance changes (improves, hopefully a lot). Once I have heard
back from you I'll look to have this included in a 7.0.1 very soon.
Kind regards, Keith Wall.
On 26 November 2017 at 14:54, Keith W <ke...@gmail.com> wrote:
> Hi Tomas
>
> Thanks for the attachments.
>
> With your Broadcaster code, which sends persistent messages
> asynchronously, I do see inferior performance from Broker J than the
> CPP Broker. I am using proton master (fa80534)
>
> Currently for this use-case, Broker-J commits synchronously after each
> delivery (see StandardReceivingLinkEndpoint#receiveDelivery. The
> pertinent part is its use of an AutoCommitTransaction and the fact
> that AutoCommitTransaction#enqueue uses a synchronous #commitTran) and
> this will explain some (if not all) of the performance difference. As
> Rob mentioned on the 10th November in this thread, the older protocols
> already have an optimisation for this use-case (involving
> AsyncAutoCommitTransaction) which should improve performance on the
> AMQP 1.0 path. This was raised as QPID-8032. I try and include this
> in a 7.0.1 soon.
>
> This doesn't explain your observation about performance when using
> Qpid JMS Client which is doing a synchronous send of persistent
> messages, but as I commented above, I cannot reproduce the problem: I
> see very similar performance for Broker-J and CPP on my hardware.
>
> cheers Keith.
>
> On 24 November 2017 at 13:06, Tomas Soltys <to...@gmail.com> wrote:
>> Hi Keith,
>>
>> Please find attached cpp_vs_java.gz
>> <http://qpid.2158936.n2.nabble.com/file/t365522/cpp_vs_java.gz> . This
>> archive contains:
>> * *java* - setup of Java broker (v7.0.0)
>> * *cpp* - setup of C++ broker (v1.36.0)
>> * *proton-client* - C++client based on Qpid proton (v0.18.1)
>> * *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
>> each) to Java broker
>> * *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
>> each) to C++ broker
>>
>> One thing I've noticed in logs is that C++ broker is sending dispositions in
>> chunks of 5 whereas Java broker does this for each message separately.
>>
>> Best regards,
>> Tomas
>>
>>
>>
>> --
>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Keith W <ke...@gmail.com>.
Hi Tomas
Thanks for the attachments.
With your Broadcaster code, which sends persistent messages
asynchronously, I do see inferior performance from Broker J than the
CPP Broker. I am using proton master (fa80534)
Currently for this use-case, Broker-J commits synchronously after each
delivery (see StandardReceivingLinkEndpoint#receiveDelivery. The
pertinent part is its use of an AutoCommitTransaction and the fact
that AutoCommitTransaction#enqueue uses a synchronous #commitTran) and
this will explain some (if not all) of the performance difference. As
Rob mentioned on the 10th November in this thread, the older protocols
already have an optimisation for this use-case (involving
AsyncAutoCommitTransaction) which should improve performance on the
AMQP 1.0 path. This was raised as QPID-8032. I try and include this
in a 7.0.1 soon.
This doesn't explain your observation about performance when using
Qpid JMS Client which is doing a synchronous send of persistent
messages, but as I commented above, I cannot reproduce the problem: I
see very similar performance for Broker-J and CPP on my hardware.
cheers Keith.
On 24 November 2017 at 13:06, Tomas Soltys <to...@gmail.com> wrote:
> Hi Keith,
>
> Please find attached cpp_vs_java.gz
> <http://qpid.2158936.n2.nabble.com/file/t365522/cpp_vs_java.gz> . This
> archive contains:
> * *java* - setup of Java broker (v7.0.0)
> * *cpp* - setup of C++ broker (v1.36.0)
> * *proton-client* - C++client based on Qpid proton (v0.18.1)
> * *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
> each) to Java broker
> * *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
> each) to C++ broker
>
> One thing I've noticed in logs is that C++ broker is sending dispositions in
> chunks of 5 whereas Java broker does this for each message separately.
>
> Best regards,
> Tomas
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Tomas Soltys <to...@gmail.com>.
Hi Keith,
Please find attached cpp_vs_java.gz
<http://qpid.2158936.n2.nabble.com/file/t365522/cpp_vs_java.gz> . This
archive contains:
* *java* - setup of Java broker (v7.0.0)
* *cpp* - setup of C++ broker (v1.36.0)
* *proton-client* - C++client based on Qpid proton (v0.18.1)
* *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
each) to Java broker
* *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
each) to C++ broker
One thing I've noticed in logs is that C++ broker is sending dispositions in
chunks of 5 whereas Java broker does this for each message separately.
Best regards,
Tomas
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Keith W <ke...@gmail.com>.
Hi Tomas,
Can I suggest that you share the logs from both brokers for the two
amq_send.sh test? Also separately, I suggest a run of amq_send.sh
with a small number of message, say message-count 20, with Proton
trace logging enabled (export PN_TRACE_FRM=true) on the client side.
Repeat this with both Brokers and share.
With regard to Broker-J performance, we know that BDB will outperform
Derby for many use-cases. The BDB plugin has received much more
tuning over the years than Derby. I know you have already said you
tested with both earlier in the thread, but I wanted to point it out.
cheers Keith
On 24 November 2017 at 10:58, Tomas Soltys <to...@gmail.com> wrote:
> Hi Robbie,
>
> I just realized that I placed my response to incorrect person. It supposed
> to be a reply to Keith's message.
>
> To your questions. The test was performed with C client based on proton
> 0.18.1. However, I got very similar results also with qpid-send tool which
> settles after each message.
>
> I've also tried sending using 0-10 and 1.0 protocol versions but no
> significant differences.
>
> I also executed test client based on Qpid JMS 0.23.0 with very similar
> results. In all cases C++ broker was able to settle and send acknowledgment
> way much faster than java broker.
>
> Is there something in the settings that can be tweaked to improve IO
> performance?
>
> Regards,
> Tomas
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Robbie Gemmell <ro...@gmail.com>.
Your earlier mail was clear Tomas, I didn't even know you replied to
me as I don't use the Nabble interface. I just wanted to reiterate it
is also important we know which client(s) and which code any
comparisons are performed with otherwise the numbers simply cant be
reasoned about fully. While different clients might act/perform
similarly in some cases against particular servers, in others cases
they can/will be very different.
The example JMS code you gave earlier is doing a synchronous send of a
persistent message, so if you are running single producer synchronous
sends on a hard disk that can only do say ~100syncs/sec, and getting
vastly faster results in one case, then something is probably awry. In
such a situation, both brokers performance should be gated by the
synchronous sends and need to sync to disk before responding to the
client. Keiths testing suggested that is the case, seeing similar
results for both brokers in his testing.
In the case of a C[++] client doing asynchronous sends then it would
currently be expected for the C++ broker to be significantly faster
based on the details Rob gave, as even if waiting for settlement after
100 messages its still mostly async in comparison. Your example code
didnt do that however, so again seeing what you are actually doing
would be needed to fully reason about it.
You mention Qpid JMS 0.23.0 below, while earlier in the thread you
mentioned 0.27.0 when giving example code. Did you actually change
clients? Did you use the same JMS application code provided in this
thread in both cases? If you did use that example JMS code, I would
actually have to start questioning if the messages are really being
persisted (and synced to disk before response) in both cases if you
are seeing radically different numbers between them.
Following Keith's suggestion would be a good idea.
Robbie
On 24 November 2017 at 10:58, Tomas Soltys <to...@gmail.com> wrote:
> Hi Robbie,
>
> I just realized that I placed my response to incorrect person. It supposed
> to be a reply to Keith's message.
>
> To your questions. The test was performed with C client based on proton
> 0.18.1. However, I got very similar results also with qpid-send tool which
> settles after each message.
>
> I've also tried sending using 0-10 and 1.0 protocol versions but no
> significant differences.
>
> I also executed test client based on Qpid JMS 0.23.0 with very similar
> results. In all cases C++ broker was able to settle and send acknowledgment
> way much faster than java broker.
>
> Is there something in the settings that can be tweaked to improve IO
> performance?
>
> Regards,
> Tomas
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Tomas Soltys <to...@gmail.com>.
Hi Robbie,
I just realized that I placed my response to incorrect person. It supposed
to be a reply to Keith's message.
To your questions. The test was performed with C client based on proton
0.18.1. However, I got very similar results also with qpid-send tool which
settles after each message.
I've also tried sending using 0-10 and 1.0 protocol versions but no
significant differences.
I also executed test client based on Qpid JMS 0.23.0 with very similar
results. In all cases C++ broker was able to settle and send acknowledgment
way much faster than java broker.
Is there something in the settings that can be tweaked to improve IO
performance?
Regards,
Tomas
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Robbie Gemmell <ro...@gmail.com>.
Could you answer my question around confirming what client you are
using for the comparison below, the C++ one or the JMS one?
I'm guessing it is the C++ one. In which case, Rob's thoughts are the
likely explanation for why the Java broker isnt any faster with it
than you are seeing, and testing with the JMS client code given will
not be able to demonstrate that same difference between the two
brokers as it is doing a synchronous publish while the C++ code isnt.
Robbie
On 23 November 2017 at 15:33, tomas.soltys <to...@gmail.com> wrote:
> Hi Keith,
>
> I'm still getting huge differences, but I still hope it is related to how I
> configured my brokers. Please find attached file brokers.gz
> <http://qpid.2158936.n2.nabble.com/file/t365522/brokers.gz> containing
> setup of my two brokers (cpp and java). Both I tried to setup to be as
> similar as possible.
>
> With my test send tool I sent 1000 messages each 102400 bytes. Tool sends
> messages asynchronously and settle after each 100-th message.
>
> Output (2001 - cpp, 2002 - java):
>
> $ time amq_send.sh --host=localhost --port=20001 --user=BE --pass="BE"
> --node-name=broadcast --subject="broadcast.PublicRejectStream"
> --message-count=1000 --print-message=0 --message-size=102400
> --settle-rate=100
> 100 messages sent
> 200 messages sent
> 300 messages sent
> 400 messages sent
> 500 messages sent
> 600 messages sent
> 700 messages sent
> 800 messages sent
> 900 messages sent
> 1000 messages sent
> Time to send = 1 [seconds]
>
> real 0m1.796s
> user 0m0.125s
> sys 0m0.050s
>
> $ time amq_send.sh --host=localhost --port=20002 --user=BE --pass="BE"
> --node-name=broadcast --subject="broadcast.PublicRejectStream"
> --message-count=1000 --print-message=0 --message-size=102400
> --settle-rate=100
> 100 messages sent
> 200 messages sent
> 300 messages sent
> 400 messages sent
> 500 messages sent
> 600 messages sent
> 700 messages sent
> 800 messages sent
> 900 messages sent
> 1000 messages sent
> Time to send = 109 [seconds]
>
> real 1m48.865s
> user 0m1.504s
> sys 0m1.558s
>
> Best regards,
> Tomas
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by "tomas.soltys" <to...@gmail.com>.
Hi Keith,
I'm still getting huge differences, but I still hope it is related to how I
configured my brokers. Please find attached file brokers.gz
<http://qpid.2158936.n2.nabble.com/file/t365522/brokers.gz> containing
setup of my two brokers (cpp and java). Both I tried to setup to be as
similar as possible.
With my test send tool I sent 1000 messages each 102400 bytes. Tool sends
messages asynchronously and settle after each 100-th message.
Output (2001 - cpp, 2002 - java):
$ time amq_send.sh --host=localhost --port=20001 --user=BE --pass="BE"
--node-name=broadcast --subject="broadcast.PublicRejectStream"
--message-count=1000 --print-message=0 --message-size=102400
--settle-rate=100
100 messages sent
200 messages sent
300 messages sent
400 messages sent
500 messages sent
600 messages sent
700 messages sent
800 messages sent
900 messages sent
1000 messages sent
Time to send = 1 [seconds]
real 0m1.796s
user 0m0.125s
sys 0m0.050s
$ time amq_send.sh --host=localhost --port=20002 --user=BE --pass="BE"
--node-name=broadcast --subject="broadcast.PublicRejectStream"
--message-count=1000 --print-message=0 --message-size=102400
--settle-rate=100
100 messages sent
200 messages sent
300 messages sent
400 messages sent
500 messages sent
600 messages sent
700 messages sent
800 messages sent
900 messages sent
1000 messages sent
Time to send = 109 [seconds]
real 1m48.865s
user 0m1.504s
sys 0m1.558s
Best regards,
Tomas
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Robbie Gemmell <ro...@gmail.com>.
On 10 November 2017 at 15:39, Vavricka <va...@gmail.com> wrote:
> Hi,
>
> hardware:
> * Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
> * 16 GB RAM
> * HDD ST500DM002-1BD142
>
> timings:
> Currently Java Broker 6.1.1 seems to behave as version 7.0.0 RC. 10 - 30
> messages per second. Interesting is when I increase message size to 10kB.
> Messages per second are same but throughput is increased ten times.
> When I use nonpersistent messages everything goes smooth. Thousand of 1kB
> messages are sent within 1 second.
>
> There are no extra JVM options, just the ones which are present in
> bin/qpid-server file.
>
> Heap and direct memory on broker is also default - -Xmx512m
> -XX:MaxDirectMemorySize=1536m. I tried to increase to four times larger ones
> -Xmx2048m -XX:MaxDirectMemorySize=6000m, but there was no change in messages
> per second.
>
> Unfortunately vmstat gives same values pro CPU, I am sending at least top
> output.
>
> 6.1.1:
> %Cpu(s): 6.9 us, 0.3 sy, 0.0 ni, 68.5 id, 24.1 wa, 0.0 hi, 0.2 si, 0.0
> st
>
> 7.0.0:
> %Cpu(s): 2.4 us, 0.4 sy, 0.0 ni, 71.2 id, 25.9 wa, 0.0 hi, 0.0 si, 0.0
> st
>
> When we tried on server where message store was stored on SAN disk, sending
> of messages increased to 500 msg/sec. With C++ broker on same machine we are
> able to send 5000 msg/sec.
>
Was that last comparison made using the code you gave for the C++
client against both Java and C++ brokers, or the JMS client against
both, or some other mixture?
While they might perform similarly in some cases the two clients act
very differently and so wont in others, so the precise combination is
important for comparison.
> ps. I cannot create queue in 7.0.0 version by webgui when queue contains '.'
> character, in 6.1.1 version queue with dot in name can be created by webgui
>
>
> Keith Wall wrote
>> Hi Tomas,
>>
>> Nor can I reproduce any discernible difference in performance between
>> 6.1.1 and the 7.0.0 RC with your Java code. I have not tried the C++
>> yet.
>>
>> Can you share with us:
>>
>> * details of the hardware (including the storage) you are using for the
>> test.
>> * the timings you seeing for your tests for both the 6.1.1 case and 7.0.0
>> RC
>> * any extra JVM options you are passing either client or broker side.
>> * size of java heap (client side) and heap and direct memory (broker)
>>
>> Can I suggest that you collect vmstat type information for both runs
>> and compare? My expectation is that CPU usage, disk I/O, and network
>> utilisation should be approximately equal between the two runs.
>>
>> cheers, Keith
>
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Vavricka <va...@gmail.com>.
Hi,
hardware:
* Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
* 16 GB RAM
* HDD ST500DM002-1BD142
timings:
Currently Java Broker 6.1.1 seems to behave as version 7.0.0 RC. 10 - 30
messages per second. Interesting is when I increase message size to 10kB.
Messages per second are same but throughput is increased ten times.
When I use nonpersistent messages everything goes smooth. Thousand of 1kB
messages are sent within 1 second.
There are no extra JVM options, just the ones which are present in
bin/qpid-server file.
Heap and direct memory on broker is also default - -Xmx512m
-XX:MaxDirectMemorySize=1536m. I tried to increase to four times larger ones
-Xmx2048m -XX:MaxDirectMemorySize=6000m, but there was no change in messages
per second.
Unfortunately vmstat gives same values pro CPU, I am sending at least top
output.
6.1.1:
%Cpu(s): 6.9 us, 0.3 sy, 0.0 ni, 68.5 id, 24.1 wa, 0.0 hi, 0.2 si, 0.0
st
7.0.0:
%Cpu(s): 2.4 us, 0.4 sy, 0.0 ni, 71.2 id, 25.9 wa, 0.0 hi, 0.0 si, 0.0
st
When we tried on server where message store was stored on SAN disk, sending
of messages increased to 500 msg/sec. With C++ broker on same machine we are
able to send 5000 msg/sec.
ps. I cannot create queue in 7.0.0 version by webgui when queue contains '.'
character, in 6.1.1 version queue with dot in name can be created by webgui
Keith Wall wrote
> Hi Tomas,
>
> Nor can I reproduce any discernible difference in performance between
> 6.1.1 and the 7.0.0 RC with your Java code. I have not tried the C++
> yet.
>
> Can you share with us:
>
> * details of the hardware (including the storage) you are using for the
> test.
> * the timings you seeing for your tests for both the 6.1.1 case and 7.0.0
> RC
> * any extra JVM options you are passing either client or broker side.
> * size of java heap (client side) and heap and direct memory (broker)
>
> Can I suggest that you collect vmstat type information for both runs
> and compare? My expectation is that CPU usage, disk I/O, and network
> utilisation should be approximately equal between the two runs.
>
> cheers, Keith
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Keith W <ke...@gmail.com>.
Hi Tomas,
I'm testing with out of the box configuration. I have tried your
configuration and still can't reproduce a slow down. I don't know your
ACL rules, but I added some. The result was the same.
I'm curious to hear the answers to the questions I posed earlier.
Hopefully that will give us a clue.
Thanks Keith.
On 10 November 2017 at 13:51, Keith W <ke...@gmail.com> wrote:
> Hi Tomas,
>
> Nor can I reproduce any discernible difference in performance between
> 6.1.1 and the 7.0.0 RC with your Java code. I have not tried the C++
> yet.
>
> Can you share with us:
>
> * details of the hardware (including the storage) you are using for the test.
> * the timings you seeing for your tests for both the 6.1.1 case and 7.0.0 RC
> * any extra JVM options you are passing either client or broker side.
> * size of java heap (client side) and heap and direct memory (broker)
>
> Can I suggest that you collect vmstat type information for both runs
> and compare? My expectation is that CPU usage, disk I/O, and network
> utilisation should be approximately equal between the two runs.
>
> cheers, Keith
>
>
> On 10 November 2017 at 11:12, Rob Godfrey <ro...@gmail.com> wrote:
>> Hi Tomas,
>>
>> on the producing side I cannot reproduce this difference on my laptop
>> (MacBook Pro, running OS X), and I'm unaware of any changes that were made
>> to the broker that would cause such a significant slowdown (I haven't
>> looked at consuming yet).
>>
>> I presume you are running these tests on the same hardware, with the same
>> JMS client version, and such...?
>>
>> -- Rob
>>
>> On 10 November 2017 at 10:11, Rob Godfrey <ro...@gmail.com> wrote:
>>
>>> Thanks Tomas,
>>>
>>> we'll look into this
>>>
>>> -- Rob
>>>
>>> On 10 November 2017 at 09:59, Vavricka <va...@gmail.com> wrote:
>>>
>>>> C++ client code below
>>>>
>>>> #include <string>
>>>> #include <iostream>
>>>>
>>>> #include <proton/connection_options.hpp>
>>>> #include <proton/container.hpp>
>>>> #include <proton/default_container.hpp>
>>>> #include <proton/message.hpp>
>>>> #include <proton/message_id.hpp>
>>>> #include <proton/messaging_handler.hpp>
>>>> #include <proton/thread_safe.hpp>
>>>> #include <proton/tracker.hpp>
>>>> #include <proton/value.hpp>
>>>>
>>>> class Broadcaster : public proton::messaging_handler
>>>> {
>>>>
>>>> private:
>>>>
>>>> std::string _account;
>>>> std::string _password;
>>>> std::string _host;
>>>> unsigned int _port;
>>>> unsigned int _count;
>>>> unsigned int _size;
>>>> unsigned int _sent;
>>>> unsigned int _confirmed;
>>>> std::string _exchange;
>>>> std::string _routingKey;
>>>> proton::sender _sender;
>>>>
>>>> public:
>>>>
>>>> explicit Broadcaster(const std::string &account,
>>>> const std::string &password,
>>>> const std::string &host,
>>>> unsigned int port,
>>>> const std::string &exchange,
>>>> const std::string &routingKey,
>>>> unsigned int count,
>>>> unsigned int size)
>>>> : _account(account)
>>>> , _password(password)
>>>> , _host(host)
>>>> , _port(port)
>>>> , _count(count)
>>>> , _size(size)
>>>> , _sent(0)
>>>> , _confirmed(0)
>>>> , _exchange(exchange)
>>>> , _routingKey(routingKey)
>>>> {
>>>> }
>>>>
>>>> void on_container_start(proton::container &c)
>>>> {
>>>> proton::connection_options connectionOptions;
>>>> connectionOptions.sasl_allow_insecure_mechs(true);
>>>> connectionOptions.sasl_allowed_mechs("PLAIN");
>>>> c.client_connection_options(connectionOptions);
>>>>
>>>> std::string url = "amqp://" + _account + ":" + _password + "@" +
>>>> _host + ":" + std::to_string(_port) + "/" + _exchange;
>>>>
>>>> _sender = c.open_sender(url);
>>>> }
>>>>
>>>> void on_sendable(proton::sender &s)
>>>> {
>>>> while (s.credit() && _sent < _count)
>>>> {
>>>> proton::message msg;
>>>> msg.id(_sent + 1);
>>>> msg.subject(_routingKey);
>>>> msg.body(std::string(_size, '*'));
>>>> msg.durable(true);
>>>> s.send(msg);
>>>> _sent++;
>>>> std::cout << "-I sent " << _sent << " of " << _count <<
>>>> std::endl;
>>>> }
>>>> }
>>>>
>>>> void on_tracker_accept(proton::tracker &t)
>>>> {
>>>> _confirmed++;
>>>> if (_confirmed == _count)
>>>> {
>>>> std::cout << "-I- All messages (" << _confirmed << ")
>>>> confirmed"
>>>> << std::endl;
>>>> t.connection().close();
>>>> }
>>>> }
>>>>
>>>> void on_transport_close(proton::transport &t)
>>>> {
>>>> _sent = _confirmed;
>>>> }
>>>>
>>>> void run()
>>>> {
>>>> try
>>>> {
>>>> proton::default_container(*this).run();
>>>> }
>>>> catch (const std::exception &error)
>>>> {
>>>> std::cerr << "-E- Caught exception: " << error.what() <<
>>>> std::endl;
>>>> throw error;
>>>> }
>>>> }
>>>> };
>>>>
>>>> int main(void)
>>>> {
>>>> Broadcaster("C7",
>>>> "C7",
>>>> "pc1wj611",
>>>> 20001,
>>>> "broadcast",
>>>> "broadcast.C7_CashTransaction",
>>>> 1000,
>>>> 1024).run();
>>>> return 0;
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936
>>>> .html
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Keith W <ke...@gmail.com>.
Hi Tomas,
Nor can I reproduce any discernible difference in performance between
6.1.1 and the 7.0.0 RC with your Java code. I have not tried the C++
yet.
Can you share with us:
* details of the hardware (including the storage) you are using for the test.
* the timings you seeing for your tests for both the 6.1.1 case and 7.0.0 RC
* any extra JVM options you are passing either client or broker side.
* size of java heap (client side) and heap and direct memory (broker)
Can I suggest that you collect vmstat type information for both runs
and compare? My expectation is that CPU usage, disk I/O, and network
utilisation should be approximately equal between the two runs.
cheers, Keith
On 10 November 2017 at 11:12, Rob Godfrey <ro...@gmail.com> wrote:
> Hi Tomas,
>
> on the producing side I cannot reproduce this difference on my laptop
> (MacBook Pro, running OS X), and I'm unaware of any changes that were made
> to the broker that would cause such a significant slowdown (I haven't
> looked at consuming yet).
>
> I presume you are running these tests on the same hardware, with the same
> JMS client version, and such...?
>
> -- Rob
>
> On 10 November 2017 at 10:11, Rob Godfrey <ro...@gmail.com> wrote:
>
>> Thanks Tomas,
>>
>> we'll look into this
>>
>> -- Rob
>>
>> On 10 November 2017 at 09:59, Vavricka <va...@gmail.com> wrote:
>>
>>> C++ client code below
>>>
>>> #include <string>
>>> #include <iostream>
>>>
>>> #include <proton/connection_options.hpp>
>>> #include <proton/container.hpp>
>>> #include <proton/default_container.hpp>
>>> #include <proton/message.hpp>
>>> #include <proton/message_id.hpp>
>>> #include <proton/messaging_handler.hpp>
>>> #include <proton/thread_safe.hpp>
>>> #include <proton/tracker.hpp>
>>> #include <proton/value.hpp>
>>>
>>> class Broadcaster : public proton::messaging_handler
>>> {
>>>
>>> private:
>>>
>>> std::string _account;
>>> std::string _password;
>>> std::string _host;
>>> unsigned int _port;
>>> unsigned int _count;
>>> unsigned int _size;
>>> unsigned int _sent;
>>> unsigned int _confirmed;
>>> std::string _exchange;
>>> std::string _routingKey;
>>> proton::sender _sender;
>>>
>>> public:
>>>
>>> explicit Broadcaster(const std::string &account,
>>> const std::string &password,
>>> const std::string &host,
>>> unsigned int port,
>>> const std::string &exchange,
>>> const std::string &routingKey,
>>> unsigned int count,
>>> unsigned int size)
>>> : _account(account)
>>> , _password(password)
>>> , _host(host)
>>> , _port(port)
>>> , _count(count)
>>> , _size(size)
>>> , _sent(0)
>>> , _confirmed(0)
>>> , _exchange(exchange)
>>> , _routingKey(routingKey)
>>> {
>>> }
>>>
>>> void on_container_start(proton::container &c)
>>> {
>>> proton::connection_options connectionOptions;
>>> connectionOptions.sasl_allow_insecure_mechs(true);
>>> connectionOptions.sasl_allowed_mechs("PLAIN");
>>> c.client_connection_options(connectionOptions);
>>>
>>> std::string url = "amqp://" + _account + ":" + _password + "@" +
>>> _host + ":" + std::to_string(_port) + "/" + _exchange;
>>>
>>> _sender = c.open_sender(url);
>>> }
>>>
>>> void on_sendable(proton::sender &s)
>>> {
>>> while (s.credit() && _sent < _count)
>>> {
>>> proton::message msg;
>>> msg.id(_sent + 1);
>>> msg.subject(_routingKey);
>>> msg.body(std::string(_size, '*'));
>>> msg.durable(true);
>>> s.send(msg);
>>> _sent++;
>>> std::cout << "-I sent " << _sent << " of " << _count <<
>>> std::endl;
>>> }
>>> }
>>>
>>> void on_tracker_accept(proton::tracker &t)
>>> {
>>> _confirmed++;
>>> if (_confirmed == _count)
>>> {
>>> std::cout << "-I- All messages (" << _confirmed << ")
>>> confirmed"
>>> << std::endl;
>>> t.connection().close();
>>> }
>>> }
>>>
>>> void on_transport_close(proton::transport &t)
>>> {
>>> _sent = _confirmed;
>>> }
>>>
>>> void run()
>>> {
>>> try
>>> {
>>> proton::default_container(*this).run();
>>> }
>>> catch (const std::exception &error)
>>> {
>>> std::cerr << "-E- Caught exception: " << error.what() <<
>>> std::endl;
>>> throw error;
>>> }
>>> }
>>> };
>>>
>>> int main(void)
>>> {
>>> Broadcaster("C7",
>>> "C7",
>>> "pc1wj611",
>>> 20001,
>>> "broadcast",
>>> "broadcast.C7_CashTransaction",
>>> 1000,
>>> 1024).run();
>>> return 0;
>>> }
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936
>>> .html
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Vavricka <va...@gmail.com>.
Yes, we running it on same hardware and versions.
Couldn't be there issue with our configuration? Can you spot there some
misconfiguration in config files below?
Will be helpful if you send us your broker configuration?
config.json
{
"id" : "cfa9a57a-6f98-4f17-b81d-22fb5a032473",
"name" : "cps",
"modelVersion" : "7.0",
"accesscontrolproviders" : [ {
"id" : "65b550b1-0a22-4815-9b6f-5287f6a9b455",
"name" : "brokerAcl",
"type" : "AclFile",
"path" : "/home/vavrtom/qpid/0406/broker/work/broker.acl",
"lastUpdatedBy" : null,
"lastUpdatedTime" : null,
"createdBy" : null,
"createdTime" : null
} ],
"authenticationproviders" : [ {
"id" : "df3680b4-8bd7-4bb8-92b7-705d33bf1496",
"name" : "SHA_256",
"type" : "SCRAM-SHA-256",
"secureOnlyMechanisms" : [ ],
"users" : [ {
"id" : "e98445dd-4f79-46b1-bc7f-a153f546e63e",
"name" : "C7",
"type" : "managed",
"durable" : true,
"password" :
"KAkXZolpJXtHteNgxqeNaosC3eecIN0MRZVdFcAwGm4=,,U52qJCBi8jUfjPTHMxayTwUhQ3UT+N6B7h78S+kRNUw=,fQdDP2WsuAGZ/P4PxJuSAHrpmgE/2GBMjD9/TrYw0QY=,4096",
"lastUpdatedBy" : "admin",
"lastUpdatedTime" : 1510235279421,
"createdBy" : "admin",
"createdTime" : 1510235279421
}, {
"id" : "62ab34ac-11d8-4ed0-adc3-bd1c34a2f7af",
"name" : "admin",
"type" : "managed",
"password" :
"7uKre2FrpVvO+/gABKrTHyQS5tAY92UqOWNcWPCubyw=,,j3TzWP+Bg2iZUXxMdZbVi1ftrHIvzev5PqO9ftDC4hU=,9cvIWGYPfeUD0hFLvINPKz+Ddvv/9/yz8PuMC+JR3Ro=,4096"
}, {
"id" : "e6451384-9ef5-4823-81c6-7b1aff7251ca",
"name" : "monit",
"type" : "managed",
"password" :
"b3MiUviPyxYSfB9bxRZG4FJ/uxDWjWnNvBe1B/w8JYc=,,gxUMuoFhW9oVNV/tEiLm3IdgObL2uQagi63G+3bnFgs=,cQmi/8NKL2b8ESfoF/wcffPRILoMOx5cRy+rEG2TAxw=,4096"
} ]
}, {
"id" : "85d7cb16-4c60-45ca-94e8-47c611a7b1e4",
"name" : "external",
"type" : "External"
} ],
"brokerloggers" : [ {
"id" : "e637b21b-c3a8-457f-a0ff-c4327c88135b",
"name" : "logfile",
"type" : "File",
"fileName" :
"${qpid.work_dir}${file.separator}..${file.separator}..${file.separator}log${file.separator}broker.log",
"brokerloginclusionrules" : [ {
"id" : "f8e8c9eb-6ca9-4845-8ac8-1ba614a47ce8",
"name" : "Operational",
"type" : "NameAndLevel",
"level" : "INFO",
"loggerName" : "qpid.message.*"
}, {
"id" : "13c4e2c4-3b3a-43be-890b-cc506dae63f8",
"name" : "Qpid",
"type" : "NameAndLevel",
"level" : "INFO",
"loggerName" : "org.apache.qpid.*"
}, {
"id" : "00ff6321-2d42-4dce-aad0-12c55c928e0d",
"name" : "Root",
"type" : "NameAndLevel",
"level" : "INFO",
"loggerName" : "ROOT"
} ]
}, {
"id" : "b25480a7-5ed1-4035-af9d-565c9c223708",
"name" : "memory",
"type" : "Memory",
"brokerloginclusionrules" : [ {
"id" : "ffc9a1da-e812-476c-8ccf-c8ead2f15e1e",
"name" : "Operational",
"type" : "NameAndLevel",
"level" : "INFO",
"loggerName" : "qpid.message.*"
}, {
"id" : "8c2a2fe6-9531-469b-8f26-c5d449e97f26",
"name" : "Qpid",
"type" : "NameAndLevel",
"level" : "INFO",
"loggerName" : "org.apache.qpid.*"
}, {
"id" : "dcb193af-fba8-49e7-9ed4-9a4a08627e8c",
"name" : "Root",
"type" : "NameAndLevel",
"level" : "INFO",
"loggerName" : "ROOT"
} ]
} ],
"keystores" : [ {
"id" : "f262fc1c-081b-4215-8afb-bb0ce6131857",
"name" : "keyStore",
"type" : "FileKeyStore",
"certificateAlias" : "vavrtom-amqp",
"password" : "admin",
"storeUrl" : "/home/vavrtom/qpid/0406/broker/work/keystore.jks"
} ],
"plugins" : [ {
"id" : "1276ff6c-61ea-4b4d-b1ad-4edc5c02f581",
"name" : "httpManagement",
"type" : "MANAGEMENT-HTTP",
"httpBasicAuthenticationEnabled" : "true"
} ],
"ports" : [ {
"id" : "6fdbb8b1-76ba-4048-9ca8-4e7dfb884a38",
"name" : "amqp",
"type" : "AMQP",
"port" : 20406,
"protocols" : [ "AMQP_1_0" ],
"authenticationProvider" : "SHA_256",
"threadPoolSize" : 10,
"numberOfSelectors" : 1,
"maxOpenConnections" : 1000,
"virtualhostaliases" : [ {
"id" : "59d083e1-57f2-45c0-b8d4-c75f23ea33ef",
"name" : "defaultAlias",
"type" : "defaultAlias"
}, {
"id" : "1c61ebd0-fbc6-4891-998b-59b972492fc7",
"name" : "hostnameAlias",
"type" : "hostnameAlias"
}, {
"id" : "d75851d6-ea9c-4aec-a8db-7e28d5815b5e",
"name" : "nameAlias",
"type" : "nameAlias"
} ]
}, {
"id" : "f52c4129-d388-4f3a-b23f-892070a131dd",
"name" : "amqps",
"type" : "AMQP",
"port" : 10406,
"protocols" : [ "AMQP_1_0" ],
"authenticationProvider" : "external",
"needClientAuth" : true,
"wantClientAuth" : true,
"keyStore" : "keyStore",
"transports" : [ "SSL" ],
"trustStores" : [ "trustStore" ],
"threadPoolSize" : 10,
"numberOfSelectors" : 1,
"maxOpenConnections" : 1000,
"virtualhostaliases" : [ {
"id" : "692a512e-af97-42ca-8743-57872b4ed2e7",
"name" : "defaultAlias",
"type" : "defaultAlias"
}, {
"id" : "8963d8cd-aef5-4249-b8d6-65c562405dcf",
"name" : "hostnameAlias",
"type" : "hostnameAlias"
}, {
"id" : "8638b4a2-0b03-4727-a556-ef6616e9a29c",
"name" : "nameAlias",
"type" : "nameAlias"
} ]
}, {
"id" : "5ecba4e6-eff0-4e76-9853-43ffa1d1c2f3",
"name" : "http",
"type" : "HTTP",
"port" : 40406,
"authenticationProvider" : "SHA_256",
"threadPoolMinimum" : 5,
"threadPoolMaximum" : 12,
"protocols" : [ "HTTP" ],
"transports" : [ "TCP" ]
} ],
"truststores" : [ {
"id" : "7f6fb21a-9f8b-4ae8-b49e-910fff7d09d2",
"name" : "trustStore",
"type" : "FileTrustStore",
"password" : "admin",
"storeUrl" : "/home/vavrtom/qpid/0406/broker/work/truststore.jks",
"peersOnly" : true
} ],
"virtualhostnodes" : [ {
"id" : "204130eb-c179-49b9-97b3-face952ccc2c",
"name" : "default",
"type" : "JSON",
"defaultVirtualHostNode" : "true",
"virtualHostInitialConfiguration" : "{}",
"lastUpdatedBy" : null,
"lastUpdatedTime" : 1510234719667,
"createdBy" : null,
"createdTime" : 1510234718577
} ]
}
default.json
{
"id" : "4691c428-71df-47db-ab0e-ff4fad3012be",
"name" : "default",
"type" : "BDB",
"durable" : true,
"lifetimePolicy" : "PERMANENT",
"context" : {
"awaitAttainmentTimeout" : null,
"connectionThreadPoolKeepAliveTimeout" : null,
"javaGc" : null,
"home" : null,
"PATH" : null,
"JAVA" : null,
"virtualhostBlueprint" : null,
"java.specification.version" : null,
"sun.cpu.isalist" : null,
"qpid.auth.scram.iteration_count" : null,
"queue.alertThresholdMessageAge" : null,
"DBUS_SESSION_BUS_ADDRESS" : null,
"qpid.broker_default-shared-message-group" : null,
"sun.arch.data.model" : null,
"qpid.trustStore.siteSpecific.connectTimeout" : null,
"broker.messageCompressionEnabled" : null,
"virtualhost.housekeepingCheckPeriod" : null,
"java.vendor.url" : null,
"JAVA_MEM" : null,
"QPID_RUN_LOG" : null,
"qpid.amqp_port" : null,
"jdbcvirtualhost.tableNamePrefix" : null,
"sun.boot.library.path" : null,
"maxHttpFileUploadSize" : null,
"sun.java.command" : null,
"qpid.work_dir" : null,
"port.http.threadPool.maximum" : null,
"qpid.groupprovider.cloudfoundry.connectTimeout" : null,
"java.specification.vendor" : null,
"queue.holdOnPublishEnabled" : null,
"qpid.port.http.threadPool.numberOfSelectors" : null,
"java.home" : null,
"qpid.security.tls.protocolBlackList" : null,
"connection.messageCompressionThresholdSize" : null,
"qpid.auth.cache.expiration_time" : null,
"java.vm.specification.vendor" : null,
"java.specification.name" : null,
"qpid.port.http.acceptBacklog" : null,
"qpid.home_dir" : null,
"sun.management.compiler" : null,
"keyStoreFile.keyManagerFactoryAlgorithm" : null,
"java.runtime.version" : null,
"JAVA_GC" : null,
"virtualhost.disabledConnectionValidators" : null,
"keyStoreFile.keyStoreType" : null,
"PNAME" : null,
"queue.lvqKey" : null,
"qpid.compact_memory_interval" : null,
"qpid.initial_config_virtualhost_config" : null,
"queue.alertThresholdMessageSize" : null,
"jdbcvirtualhostnode.tableNamePrefix" : null,
"file.encoding" : null,
"qpid.broker.defaultPreferenceStoreAttributes" : null,
"qpid.broker.networkBufferSize" : null,
"qpid.authentication.oauth2.connectTimeout" : null,
"qpid.svnversion" : null,
"java.io.tmpdir" : null,
"qpid.broker.bdbTotalCacheSize" : null,
"java.version" : null,
"qpid.mimeTypeToFileExtension" : null,
"virtualhost.storeTransactionOpenTimeoutClose" : null,
"qpid.authentication.oauth2.readTimeout" : null,
"java.vm.specification.name" : null,
"java.awt.printerjob" : null,
"broker.failOnLoggerIOError" : null,
"QPID_PNAME" : null,
"java.library.path" : null,
"java.vendor" : null,
"connection.high_prefetch_limit" : null,
"sun.io.unicode.encoding" : null,
"qpid.groupprovider.cloudfoundry.readTimeout" : null,
"trustStoreFile.trustManagerFactoryAlgorithm" : null,
"virtualhost.storeTransactionOpenTimeoutWarn" : null,
"qpid.initialConfigurationLocation" : null,
"queue.defaultMaximumQueueDepthBytes" : null,
"queue.alertThresholdQueueDepthBytes" : null,
"connection.maximumAuthenticationDelay" : null,
"qpid.httpManagement.preferenceOperationTimeout" : null,
"qpid.broker.housekeepingCheckPeriod" : null,
"queue.defaultEnsureNonDestructiveConsumers" : null,
"user.timezone" : null,
"os.name" : null,
"java.vm.specification.version" : null,
"LOGNAME" : null,
"SHELL" : null,
"broker.name" : null,
"user.home" : null,
"systemConfig.tableNamePrefix" : null,
"qpid.version.suffix" : null,
"channel.flowControlEnforcementTimeout" : null,
"java.awt.graphicsenv" : null,
"qpid.security.tls.cipherSuiteBlackList" : null,
"broker.directByteBufferPoolSize" : null,
"virtualhost.work_dir" : null,
"connection.maxUncommittedInMemorySize" : null,
"qpid.port.http.threadPool.numberOfAcceptors" : null,
"XFILESEARCHPATH" : null,
"path.separator" : null,
"os.version" : null,
"java.endorsed.dirs" : null,
"queue.defaultMessageDurability" : null,
"java.vm.name" : null,
"consumer.suspendNotificationPeriod" : null,
"queue.alertRepeatGap" : null,
"qpid.port.amqp.threadPool.keep_alive_timeout" : null,
"os.arch" : null,
"qpid.queue.scavenge_count" : null,
"httpManagement.compressResponses" : null,
"CLASSPATH" : null,
"producer.authCacheSize" : null,
"qpid.port.closeWhenNoRoute" : null,
"virtualhost.enabledConnectionValidators" : null,
"java.vm.info" : null,
"connection.closeResponseTimeout" : null,
"qpid.name" : null,
"ldap.context.factory" : null,
"store.filesystem.maxUsagePercent" : null,
"XDG_RUNTIME_DIR" : null,
"java.class.version" : null,
"HOME" : null,
"qpid.auth.cache.iteration_count" : null,
"awt.toolkit" : null,
"virtualhost.connectionThreadPool.size" : null,
"queue.defaultExclusivityPolicy" : null,
"producer.authCacheTimeout" : null,
"sun.jnu.encoding" : null,
"qpid.trustStore.siteSpecific.readTimeout" : null,
"qpid.port.max_open_connections" : null,
"virtualhost.flowToDiskCheckPeriod" : null,
"qpid.httpManagement.saslExchangeExpiry" : null,
"broker.failStartupWithErroredChild" : null,
"qpid.default_posix_file_permissions" : null,
"PWD" : null,
"LANGUAGE" : null,
"qpid.compact_memory_threshold" : null,
"qpid.keystore.certificateExpiryCheckFrequency" : null,
"qpid.broker_msg_auth" : null,
"qpid.helpURL" : null,
"qpid.http_port" : null,
"queue.alertThresholdQueueDepthMessages" : null,
"qpid.port.open_connections_warn_percent" : null,
"file.separator" : null,
"line.separator" : null,
"port.http.threadPool.minimum" : null,
"LC_ALL" : null,
"virtualhost.storeTransactionIdleTimeoutWarn" : null,
"SHLVL" : null,
"sun.boot.class.path" : null,
"java.protocol.handler.pkgs" : null,
"user.name" : null,
"qpid.port.amqp.threadPool.size" : null,
"qpid.port.sessionCountLimit" : null,
"XDG_SESSION_ID" : null,
"qpid.port.amqp.acceptBacklog" : null,
"broker.housekeepingThreadCount" : null,
"no_proxy" : null,
"queue.defaultMaximumQueueDepthMessages" : null,
"SSH_CLIENT" : null,
"qpid.broker_heartbeat_timeout_factor" : null,
"queue.maximumDeliveryAttempts" : null,
"qpid.security.tls.protocolWhiteList" : null,
"queue.defaultOverflowPolicy" : null,
"virtualhost.connectionThreadPool.numberOfSelectors" : null,
"qpid.port.protocol_handshake_timeout" : null,
"sun.os.patch.level" : null,
"SSH_CONNECTION" : null,
"qpid.port.amqp.threadPool.numberOfSelectors" : null,
"NLSPATH" : null,
"EXTERNAL_CLASSPATH" : null,
"broker.flowToDiskThreshold" : null,
"virtualhost.housekeepingThreadCount" : null,
"connection.sendQueueDeleteOkRegardlessClientVerRegexp" : null,
"https_proxy" : null,
"file.encoding.pkg" : null,
"java.class.path" : null,
"java.vm.vendor" : null,
"brokermemorylogger.max_record_limit" : null,
"qpid.security.tls.cipherSuiteWhiteList" : null,
"qpid.session.transactionTimeoutNotificationRepeatPeriod" : null,
"MAIL" : null,
"QPID_HOME" : null,
"user.country" : null,
"sun.java.launcher" : null,
"QPID_CLASSPATH" : null,
"derby.stream.error.method" : null,
"queue.maximumDistinctGroups" : null,
"sun.cpu.endian" : null,
"connection.batch_limit" : null,
"JAVA_VM" : null,
"user.language" : null,
"qpid.keystore.certificateExpiryWarnPeriod" : null,
"QPID_WORK" : null,
"queue.priorities" : null,
"queue.queueFlowResumeLimit" : null,
"connection.sendSaslFinalResponseAsChallenge" : null,
"qpid.max_message_size" : null,
"LANG" : null,
"java.runtime.name" : null,
"virtualhost.storeTransactionIdleTimeoutClose" : null,
"broker.directByteBufferPoolSparsityReallocationFraction" : null,
"qpid.version" : null,
"connection.sessionCreditWindowSize" : null,
"http_proxy" : null,
"java.vendor.url.bug" : null,
"qpid.port.default_amqp_protocols" : null,
"trustStoreFile.trustStoreType" : null,
"qpid.port.heartbeatDelay" : "30",
"user.dir" : null,
"QPID_PID_FILENAME" : null,
"USER" : null,
"qpid.auth.cache.size" : null,
"java.vm.version" : null,
"java.ext.dirs" : null
},
"connectionThreadPoolSize" : 64,
"housekeepingCheckPeriod" : 30000,
"housekeepingThreadCount" : 4,
"modelVersion" : "7.0",
"numberOfSelectors" : 8,
"storeOverfullSize" : 0,
"storePath" : "/home/vavrtom/qpid/0406/broker/work/default/messages",
"storeTransactionIdleTimeoutClose" : 0,
"storeTransactionIdleTimeoutWarn" : 180000,
"storeTransactionOpenTimeoutClose" : 0,
"storeTransactionOpenTimeoutWarn" : 300000,
"storeUnderfullSize" : 0,
"lastUpdatedBy" : "admin",
"lastUpdatedTime" : 1510235279795,
"createdBy" : null,
"createdTime" : 1510234719506,
"exchanges" : [ {
"id" : "4510de36-a0f3-448a-819b-ac572014b6d6",
"name" : "amq.direct",
"type" : "direct",
"lastUpdatedTime" : 1510234719506,
"createdTime" : 1510234719506
}, {
"id" : "6184cac5-1764-4cf2-b3f0-d07a048151ef",
"name" : "amq.fanout",
"type" : "fanout",
"lastUpdatedTime" : 1510234719506,
"createdTime" : 1510234719506
}, {
"id" : "0098767e-bcbd-4974-af7b-74221cda4eee",
"name" : "amq.match",
"type" : "headers",
"lastUpdatedTime" : 1510234719506,
"createdTime" : 1510234719506
}, {
"id" : "27e67bc6-5ed7-4db9-b333-9854758f1209",
"name" : "amq.topic",
"type" : "topic",
"lastUpdatedTime" : 1510234719506,
"createdTime" : 1510234719506
}, {
"id" : "f16a6753-be77-48fa-bfb0-b7658fce52e8",
"name" : "broadcast",
"type" : "topic",
"durable" : true,
"durableBindings" : [ {
"arguments" : { },
"destination" : "broadcast.C7_PAYMENT.C7_CashTransaction",
"bindingKey" : "broadcast.C7_CashTransaction.#"
} ],
"lastUpdatedBy" : "admin",
"lastUpdatedTime" : 1510319208090,
"createdBy" : "admin",
"createdTime" : 1510234748147
} ],
"queues" : [ {
"id" : "c2b55b49-08bf-4158-a673-f59b2b05018d",
"name" : "broadcast.C7_PAYMENT.C7_CashTransaction",
"type" : "standard",
"durable" : true,
"alertRepeatGap" : 0,
"alertThresholdMessageAge" : 0,
"alertThresholdMessageSize" : 0,
"alertThresholdQueueDepthBytes" : 0,
"alertThresholdQueueDepthMessages" : 0,
"ensureNondestructiveConsumers" : false,
"holdOnPublishEnabled" : false,
"maximumDeliveryAttempts" : 0,
"maximumDistinctGroups" : 0,
"maximumMessageTtl" : 0,
"maximumQueueDepthBytes" : -1,
"maximumQueueDepthMessages" : -1,
"messageDurability" : "DEFAULT",
"minimumMessageTtl" : 0,
"noLocal" : false,
"overflowPolicy" : "REJECT",
"owner" : null,
"lastUpdatedBy" : "admin",
"lastUpdatedTime" : 1510234747878,
"createdBy" : "admin",
"createdTime" : 1510234747878
} ]
}
rgodfrey wrote
> Hi Tomas,
>
> on the producing side I cannot reproduce this difference on my laptop
> (MacBook Pro, running OS X), and I'm unaware of any changes that were made
> to the broker that would cause such a significant slowdown (I haven't
> looked at consuming yet).
>
> I presume you are running these tests on the same hardware, with the same
> JMS client version, and such...?
>
> -- Rob
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Rob Godfrey <ro...@gmail.com>.
Hi Tomas,
on the producing side I cannot reproduce this difference on my laptop
(MacBook Pro, running OS X), and I'm unaware of any changes that were made
to the broker that would cause such a significant slowdown (I haven't
looked at consuming yet).
I presume you are running these tests on the same hardware, with the same
JMS client version, and such...?
-- Rob
On 10 November 2017 at 10:11, Rob Godfrey <ro...@gmail.com> wrote:
> Thanks Tomas,
>
> we'll look into this
>
> -- Rob
>
> On 10 November 2017 at 09:59, Vavricka <va...@gmail.com> wrote:
>
>> C++ client code below
>>
>> #include <string>
>> #include <iostream>
>>
>> #include <proton/connection_options.hpp>
>> #include <proton/container.hpp>
>> #include <proton/default_container.hpp>
>> #include <proton/message.hpp>
>> #include <proton/message_id.hpp>
>> #include <proton/messaging_handler.hpp>
>> #include <proton/thread_safe.hpp>
>> #include <proton/tracker.hpp>
>> #include <proton/value.hpp>
>>
>> class Broadcaster : public proton::messaging_handler
>> {
>>
>> private:
>>
>> std::string _account;
>> std::string _password;
>> std::string _host;
>> unsigned int _port;
>> unsigned int _count;
>> unsigned int _size;
>> unsigned int _sent;
>> unsigned int _confirmed;
>> std::string _exchange;
>> std::string _routingKey;
>> proton::sender _sender;
>>
>> public:
>>
>> explicit Broadcaster(const std::string &account,
>> const std::string &password,
>> const std::string &host,
>> unsigned int port,
>> const std::string &exchange,
>> const std::string &routingKey,
>> unsigned int count,
>> unsigned int size)
>> : _account(account)
>> , _password(password)
>> , _host(host)
>> , _port(port)
>> , _count(count)
>> , _size(size)
>> , _sent(0)
>> , _confirmed(0)
>> , _exchange(exchange)
>> , _routingKey(routingKey)
>> {
>> }
>>
>> void on_container_start(proton::container &c)
>> {
>> proton::connection_options connectionOptions;
>> connectionOptions.sasl_allow_insecure_mechs(true);
>> connectionOptions.sasl_allowed_mechs("PLAIN");
>> c.client_connection_options(connectionOptions);
>>
>> std::string url = "amqp://" + _account + ":" + _password + "@" +
>> _host + ":" + std::to_string(_port) + "/" + _exchange;
>>
>> _sender = c.open_sender(url);
>> }
>>
>> void on_sendable(proton::sender &s)
>> {
>> while (s.credit() && _sent < _count)
>> {
>> proton::message msg;
>> msg.id(_sent + 1);
>> msg.subject(_routingKey);
>> msg.body(std::string(_size, '*'));
>> msg.durable(true);
>> s.send(msg);
>> _sent++;
>> std::cout << "-I sent " << _sent << " of " << _count <<
>> std::endl;
>> }
>> }
>>
>> void on_tracker_accept(proton::tracker &t)
>> {
>> _confirmed++;
>> if (_confirmed == _count)
>> {
>> std::cout << "-I- All messages (" << _confirmed << ")
>> confirmed"
>> << std::endl;
>> t.connection().close();
>> }
>> }
>>
>> void on_transport_close(proton::transport &t)
>> {
>> _sent = _confirmed;
>> }
>>
>> void run()
>> {
>> try
>> {
>> proton::default_container(*this).run();
>> }
>> catch (const std::exception &error)
>> {
>> std::cerr << "-E- Caught exception: " << error.what() <<
>> std::endl;
>> throw error;
>> }
>> }
>> };
>>
>> int main(void)
>> {
>> Broadcaster("C7",
>> "C7",
>> "pc1wj611",
>> 20001,
>> "broadcast",
>> "broadcast.C7_CashTransaction",
>> 1000,
>> 1024).run();
>> return 0;
>> }
>>
>>
>>
>>
>> --
>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936
>> .html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
Re: Java Broker performance
Posted by Rob Godfrey <ro...@gmail.com>.
Thanks Tomas,
we'll look into this
-- Rob
On 10 November 2017 at 09:59, Vavricka <va...@gmail.com> wrote:
> C++ client code below
>
> #include <string>
> #include <iostream>
>
> #include <proton/connection_options.hpp>
> #include <proton/container.hpp>
> #include <proton/default_container.hpp>
> #include <proton/message.hpp>
> #include <proton/message_id.hpp>
> #include <proton/messaging_handler.hpp>
> #include <proton/thread_safe.hpp>
> #include <proton/tracker.hpp>
> #include <proton/value.hpp>
>
> class Broadcaster : public proton::messaging_handler
> {
>
> private:
>
> std::string _account;
> std::string _password;
> std::string _host;
> unsigned int _port;
> unsigned int _count;
> unsigned int _size;
> unsigned int _sent;
> unsigned int _confirmed;
> std::string _exchange;
> std::string _routingKey;
> proton::sender _sender;
>
> public:
>
> explicit Broadcaster(const std::string &account,
> const std::string &password,
> const std::string &host,
> unsigned int port,
> const std::string &exchange,
> const std::string &routingKey,
> unsigned int count,
> unsigned int size)
> : _account(account)
> , _password(password)
> , _host(host)
> , _port(port)
> , _count(count)
> , _size(size)
> , _sent(0)
> , _confirmed(0)
> , _exchange(exchange)
> , _routingKey(routingKey)
> {
> }
>
> void on_container_start(proton::container &c)
> {
> proton::connection_options connectionOptions;
> connectionOptions.sasl_allow_insecure_mechs(true);
> connectionOptions.sasl_allowed_mechs("PLAIN");
> c.client_connection_options(connectionOptions);
>
> std::string url = "amqp://" + _account + ":" + _password + "@" +
> _host + ":" + std::to_string(_port) + "/" + _exchange;
>
> _sender = c.open_sender(url);
> }
>
> void on_sendable(proton::sender &s)
> {
> while (s.credit() && _sent < _count)
> {
> proton::message msg;
> msg.id(_sent + 1);
> msg.subject(_routingKey);
> msg.body(std::string(_size, '*'));
> msg.durable(true);
> s.send(msg);
> _sent++;
> std::cout << "-I sent " << _sent << " of " << _count <<
> std::endl;
> }
> }
>
> void on_tracker_accept(proton::tracker &t)
> {
> _confirmed++;
> if (_confirmed == _count)
> {
> std::cout << "-I- All messages (" << _confirmed << ")
> confirmed"
> << std::endl;
> t.connection().close();
> }
> }
>
> void on_transport_close(proton::transport &t)
> {
> _sent = _confirmed;
> }
>
> void run()
> {
> try
> {
> proton::default_container(*this).run();
> }
> catch (const std::exception &error)
> {
> std::cerr << "-E- Caught exception: " << error.what() <<
> std::endl;
> throw error;
> }
> }
> };
>
> int main(void)
> {
> Broadcaster("C7",
> "C7",
> "pc1wj611",
> 20001,
> "broadcast",
> "broadcast.C7_CashTransaction",
> 1000,
> 1024).run();
> return 0;
> }
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
> f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Java Broker performance
Posted by Vavricka <va...@gmail.com>.
C++ client code below
#include <string>
#include <iostream>
#include <proton/connection_options.hpp>
#include <proton/container.hpp>
#include <proton/default_container.hpp>
#include <proton/message.hpp>
#include <proton/message_id.hpp>
#include <proton/messaging_handler.hpp>
#include <proton/thread_safe.hpp>
#include <proton/tracker.hpp>
#include <proton/value.hpp>
class Broadcaster : public proton::messaging_handler
{
private:
std::string _account;
std::string _password;
std::string _host;
unsigned int _port;
unsigned int _count;
unsigned int _size;
unsigned int _sent;
unsigned int _confirmed;
std::string _exchange;
std::string _routingKey;
proton::sender _sender;
public:
explicit Broadcaster(const std::string &account,
const std::string &password,
const std::string &host,
unsigned int port,
const std::string &exchange,
const std::string &routingKey,
unsigned int count,
unsigned int size)
: _account(account)
, _password(password)
, _host(host)
, _port(port)
, _count(count)
, _size(size)
, _sent(0)
, _confirmed(0)
, _exchange(exchange)
, _routingKey(routingKey)
{
}
void on_container_start(proton::container &c)
{
proton::connection_options connectionOptions;
connectionOptions.sasl_allow_insecure_mechs(true);
connectionOptions.sasl_allowed_mechs("PLAIN");
c.client_connection_options(connectionOptions);
std::string url = "amqp://" + _account + ":" + _password + "@" +
_host + ":" + std::to_string(_port) + "/" + _exchange;
_sender = c.open_sender(url);
}
void on_sendable(proton::sender &s)
{
while (s.credit() && _sent < _count)
{
proton::message msg;
msg.id(_sent + 1);
msg.subject(_routingKey);
msg.body(std::string(_size, '*'));
msg.durable(true);
s.send(msg);
_sent++;
std::cout << "-I sent " << _sent << " of " << _count <<
std::endl;
}
}
void on_tracker_accept(proton::tracker &t)
{
_confirmed++;
if (_confirmed == _count)
{
std::cout << "-I- All messages (" << _confirmed << ") confirmed"
<< std::endl;
t.connection().close();
}
}
void on_transport_close(proton::transport &t)
{
_sent = _confirmed;
}
void run()
{
try
{
proton::default_container(*this).run();
}
catch (const std::exception &error)
{
std::cerr << "-E- Caught exception: " << error.what() <<
std::endl;
throw error;
}
}
};
int main(void)
{
Broadcaster("C7",
"C7",
"pc1wj611",
20001,
"broadcast",
"broadcast.C7_CashTransaction",
1000,
1024).run();
return 0;
}
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Keith W <ke...@gmail.com>.
Hi Tomas,
That does sound surprising. These performance tests[1] are run, with
BDB and using the latest Qpid JMS Client, against both the Broker-J
7.0.0 and 6.1.4 code lines each day, which is consistently showing
v7.0.0 is faster for the five use-cases exercised by the tests (see
perftests/etc/testdefs/defaultTests.js). I am interested to hear
about your use-case. Do you have code you can share?
cheers, Keith.
[1] https://cwiki.apache.org/confluence/display/qpid/Running+Performance+Tests
On 9 November 2017 at 15:21, Rob Godfrey <ro...@gmail.com> wrote:
> Hi Tomas,
>
> are you saying that there is a significant degradation in performance
> between 7.0.0 and prior versions for this scenario, or do you see the same
> performance in 6.1.x?
>
> In terms of consuming - is the performance slow if you are consuming from a
> queue with 1000 messages already in it, or is the slowness just caused by
> the slow producer?
>
> Thanks,
> Rob
>
>
> On 9 November 2017 at 07:10, Vavricka <va...@gmail.com> wrote:
>
>> Hi,
>>
>> we are testing release candidate of Java Broker 7.0.0.
>>
>> I checkout tag 7.0.0, build broker with tests without any problem.
>>
>> We have sender and receiver based on proton 0.18.1.
>> Both sender and receiver are started at same time.
>> Sender is sending 1000 persistent messages to exchange and receiver expects
>> 1000 messages in queue. Messages have size 1 kB.
>> We tried DERBY and BDB as persistent storage.
>>
>> Sending and consuming of durable messages is slow (10 messages per second).
>> When sending non-persistent messages then broker behaves as expected.
>>
>> Is there some settings that can optimize persistent storage?
>>
>> Tomas
>>
>>
>>
>> --
>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
>> f2158936.html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Java Broker performance
Posted by Rob Godfrey <ro...@gmail.com>.
Hi Tomas,
are you saying that there is a significant degradation in performance
between 7.0.0 and prior versions for this scenario, or do you see the same
performance in 6.1.x?
In terms of consuming - is the performance slow if you are consuming from a
queue with 1000 messages already in it, or is the slowness just caused by
the slow producer?
Thanks,
Rob
On 9 November 2017 at 07:10, Vavricka <va...@gmail.com> wrote:
> Hi,
>
> we are testing release candidate of Java Broker 7.0.0.
>
> I checkout tag 7.0.0, build broker with tests without any problem.
>
> We have sender and receiver based on proton 0.18.1.
> Both sender and receiver are started at same time.
> Sender is sending 1000 persistent messages to exchange and receiver expects
> 1000 messages in queue. Messages have size 1 kB.
> We tried DERBY and BDB as persistent storage.
>
> Sending and consuming of durable messages is slow (10 messages per second).
> When sending non-persistent messages then broker behaves as expected.
>
> Is there some settings that can optimize persistent storage?
>
> Tomas
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
> f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>