two example proton-C engine clients, speed test, request for criticism, offer to bribe participants

[Michael Goulish <mg...@redhat.com>]

I have a couple example Proton C clients, written against 
the Engine and Driver interfaces, that I have tried to make
as Simple As Possible.  

What I would like is to receive some Suggestions, Pointers,
Hints, Ideas, Notions, Concepts, Schemes, or Hypotheses as to 
how to make it better.

On my laptop  (Thinkpad T530) I'm getting about 90,000 messages
per second, on a test of 5 million messages, but I'm not sure 
that number is valid yet because the receiver is growing its 
memory footprint rapidly.



The clients are in a little git thing, here:
  https://github.com/mick-goulish/proton_c_clients.git
  


Could they be faster?  
Do I have the right idea about how to use these interfaces?
Can I do something to prevent the receiver mem-bloat?



The messages are small -- and the two teensy test scripts 
lock the sender and receiver on separate processors.

Thanks in advance for any advice & c.  



Finally, it gives me great pleasure to announce that, for anyone
who can offer me useful tips on this code, if you ever come to
the Red Hat office in Westford, Massachusetts, Rafi Schloming will
be happy to buy you a beer.

Re: two example proton-C engine clients, speed test, request for criticism, offer to bribe participants

[Gordon Sim <gs...@redhat.com>]

On 08/20/2014 09:48 PM, Michael Goulish wrote:
>
>
> I have a couple example Proton C clients, written against
> the Engine and Driver interfaces, that I have tried to make
> as Simple As Possible.
>
> What I would like is to receive some Suggestions, Pointers,
> Hints, Ideas, Notions, Concepts, Schemes, or Hypotheses as to
> how to make it better.

Using the support for 'events' would I think make it simpler. There are 
different ways to measure 'better' of course.

> On my laptop  (Thinkpad T530) I'm getting about 90,000 messages
> per second, on a test of 5 million messages, but I'm not sure
> that number is valid yet because the receiver is growing its
> memory footprint rapidly.

That sounds like perhaps you aren't settling the messages. I believe 
pn_delivery_updated() is true when the remote peer updates the state. In 
this case the receiver is updating the state itself and so should just 
call pn_delivery_settle() after that.