Thanks Rafi. I do indeed see a difference in how long it takes to send the 
messages when I use all the credit at once. 
However, I was seeing an overall slowdown in how long it takes to settle all 
the messages. The rest of this message is just a commentary and theory on the 
slowdown. 

I'm sending 100,000 messages. The receiver is calling .drain(100000)
Scenario 1 - I send a single message in onFlow:
- The total time it takes before all messages are SENT is approx 6 seconds
- The total time it takes before all messages are SETTLED is approx 6 seconds
- The settlements come in as the messages are sent 

Scenario 2 - I send as many messages as I have credit for in onFlow:
- The total time it takes before all messages are SENT is approx 1.5 seconds
- The total time it takes before all messages are SETTLED is approx 22 seconds
- The settlements start after all messages are sent

One clue as to the reason for the dramatic increase in total settlement time is 
that the rate of settlement increases as the number of deliveries remaining to 
be settled decreases. In my receiver, I'm printing a '*' for every 1000 
settlements. At first the *s come about .5 seconds apart, but they increase in 
speed in what appears to be a linear fashion.

>From this I'm guessing there is a list traversal of all unsettled deliveries 
>happening in the engine. And indeed, if I decrease the receiver's credit 
>window to .drain(1000), the settlements come in as expected.

Scenario 3 - I send as many messages as I have credit for in onFlow but the 
credit window is 1000
- The total time it takes before all messages are SENT is approx 4 seconds
- The total time it takes before all messages are SETTLED is approx 4 seconds
- The settlements come in as each batch of messages are sent

I'll do a jprofiler run on the receiver for scenario 2 and see what I find.

----- Original Message -----
> From: "Rafael Schloming" <r...@alum.mit.edu>
> To: proton@qpid.apache.org
> Sent: Friday, October 10, 2014 12:55:45 PM
> Subject: Re: jprofiler hotspot results for java engine clients
> 
> I think if you change the innermost "if" statement in your onFlow handler
> to a "while" you should see significantly improved performance.
> 
> Flow events are generated when credit levels change. This happens at two
> different times, 1) when the receiver grants more credit to the sender, and
> 2) when the sender actually uses some of that credit by writing a message
> to the wire. The way you have coded your event handler, even if the
> receiver sends you 10,000 credits, you are only going to send a single
> message until you get another flow event, and this won't happen until you
> write the first message out onto the wire. This is going to introduce some
> added processing and latency and therefore be significantly less efficient
> than if you use up your credit in larger chunks than one message at a time.
> 
> --Rafael
> 
> 
> On Thu, Oct 9, 2014 at 2:48 PM, Ernest Allen <eal...@redhat.com> wrote:
> 
> > ----- Original Message -----
> > > From: "Rafael Schloming" <r...@alum.mit.edu>
> > > To: proton@qpid.apache.org
> > > Sent: Thursday, October 9, 2014 10:43:09 AM
> > > Subject: Re: jprofiler hotspot results for java engine clients
> > >
> > > Can you include a bit more context? The 6-7 seconds for 100,000 messages
> > > seems a bit slow compared to what I've been able to measure. Was it over
> > > loopback or a real network? Was the profiler running when those
> > > measurements were made? How big are the messages, etc?
> >
> > It was just on my laptop using 0.0.0.0. I'll try on a more powerful lab
> > machine.
> > The profiler was not running. I ran both from command line.
> > The messages are small: "Hello World".
> > I'm starting the clock after all connections are made, just before I send
> > the 1st message.
> > I stop the clock when the last message is remotelySettled in the
> > onDelivery event handler.
> >
> > I'm just sending a single message every time the onFlow handler is called.
> > I could put a loop in onFlow and send all the messages at once.
> > I was able to reduce the time to a little over 5 seconds by removing all
> > string manipulations out of the onFlow event handler.
> >
> > >
> > > ---Rafael
> > >
> > > On Thu, Oct 9, 2014 at 10:10 AM, Ernest Allen <eal...@redhat.com> wrote:
> > >
> > > > There are some java apps based on the 0.8 engine api available at
> > > > https://github.com/ErnieAllen/jprofile-clients. They are based on the
> > > > clients at https://github.com/rhs/qpid-proton-demo
> > > > They will send/receive 100,000 messages and measure the elapsed time.
> > They
> > > > are averaging between 6 and 7 seconds for the 100,000 messages.
> > > >
> > > > I used these clients to run jprofiler. Reports showing which java
> > methods
> > > > are hotspots are at
> > > > http://misc-eapages.rhcloud.com/jprofiler-results/send/Hot_Spots.html
> > > > http://misc-eapages.rhcloud.com/jprofiler-results/recv/Hot_Spots.html
> > > >
> > > > If anyone has suggestions as to how to improve the clients' throughput
> > or
> > > > would like to see a different jprofiler graph, please let me know.
> > > >
> > > > -Ernie
> > > >
> > > >
> > > >
> > >
> >
> 

Reply via email to