[Qpid-proton-cpp] Performance regression found in 0.29.0

[Rabih M]

Hello,

We are upgrading in our code the proton version from 0.27.0 to 0.29.0.
While running our unit tests, we found a considerable performance
regression.

We were able to reproduce the regression in a very simple use case.
Please find the code attached.

This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 73 ms in
0.29.0 .

Do you know what might be the cause?
We will try to investigate in parallel from our side, too.

Thanks,
Rabih & Ali
#include 
#include 
#include 

#include 

class handler : public proton::messaging_handler {

public:
   handler(const std::string& u) : url(u) {}
private:
   void on_container_start(proton::container& c)override 
   {
  c.connect(url, proton::connection_options().sasl_enabled(false));
   }

   void on_connection_open(proton::connection& c)override 
   {
  c.close();
   }

   std::string url;
};


int main()
{
   try
   {
  handler h("127.0.0.1:1234"); //wrong port
  proton::container(h).run();
   }
   catch (std::exception e)
   {
  std::cout << "Exception thrown at the client side: " << e.what();
   }
   return 0;
}


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Order of receivers from qpid::Session::nextReceiver() (with high load)

[Gordon Sim]

On 12/11/2019 6:35 pm, Toralf Lund wrote:

Good evening, all.

I have an application that uses qpid::Session::nextReceiver() to handle 
data from 3 or 4 different AMQP 0-10 message queues - it follows the 
pattern from 
https://qpid.apache.org/releases/qpid-cpp-1.39.0/messaging-api/book/ch01s08.html. 



Question: If multiple receivers are ready when nextReceiver() is called, 
which one should I expect to be returned? Is there a well-defined order 
or priority?


The destinations returned should be in the order the messages are 
received, providing you are only fetching a single message after each 
return from nextReceiver(). (And are not otherwise interacting with 
receivers on the session).


In more detail, the way the code works is that there is a lower layer 
that the messaging API call on, which should return frames for the 
session in the order they are read from the wire.


However there are different ways the messaging api provides to interact 
with this. The messaging session maintains a list of frames received 
from the lower layer that have not been 'handled' in some way by the 
application. E.g. if you have two receivers, are receiving messages for 
each, but call fetch in a loop on just one of them, then the messages 
for the other receiver will be kept in this queue until that receiver 
fetches.


The nextReceiver() call will return the receiver associated with the 
first message in that list (retrieving one from the lower layer if that 
list is empty). If you then call fetch on that receiver, it should 
remove that message and return it.


What if new messages keep appearing, so a given call will 
never, or rarely, see just one ready receiver?


I think my application sometimes, due to a performance issue that's yet 
to be resolved, gets into that situation, i.e. more than one receiver is 
ready, and at least one more gets ready before the subsequent 
nextReceiver() call. That means the system is not able to handle all 
incoming messages, but it may look like this mostly affects only one 
receiver - it's as if nextReceiver() almost never gets to it because 
data keeps appearing on the others, or something. The queue associated 
with the receiver happens to get new data at a slightly lower rate than 
some of the others, and its message are also *much* larger. Does that 
make any sense at all?


If when you get a receiver from nextReceiver() you keep calling fetch on 
that, then it would mean that messages received on other receivers would 
be queued up in the sessions list awaiting processing by a call to fetch 
on those receivers.


If you only make a single fetch() call on the receiver returned from 
nextReceiver(), then return to nextReceiver() then I can't see any 
reason why one receiver that is receiving messages would not be 
returned. That said, it is of course always possible that I am missing 
something in my analysis of the code.


Are you able to get any detailed logging from a case where this is 
happening? Are you able to reproduce it?



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org