Clever Geek Handbook

Is the ZeroMQ Poll function over-CPU on .NET?

I have a simple console application that uses ZeroMQ to send and receive messages. On the receiving end, I have the following message pump code:

   ZMQ.Context _context = new ZMQ.Context(1);

   ZMQ.PollItem[] pollItems = new ZMQ.PollItem[0];

   while (!_finished)
   {
       if (pollItems.Length > 0)
           context.Poll(pollItems, pollTimeout);
       else
           Thread.Sleep(1);

       if (_receiversChanged)
           UpdatePollItems(ref pollItems);
   }

(The idea is that I can add and remove items from the poller at runtime, since I need to add receivers. UpdatePollItems just creates a new array whenever the receiver set changes.)

I've tried pollTimeout values ​​of 50ms and 500ms, but the app (which sits on the main thread on the Console.ReadKey) still uses 100% of one core even when no messages are sent. I ran the app under a profiler and confirmed that it is ZMQ.Context.Poller chewing on the entire cpu.

Have other people experienced similar behavior? I am using the latest ZeroMQ C # binding (clrzmq-x64.2.2.3 from NuGet).

+3


source to share


2 answers


Yes, there is a bug in the driver. I hit too. If you look at the code, it is possible that the .net 4 version should be better, but you should recompile it. I will check if the code I have rewritten can be reintegrated as a pull request.



+4


source


I'm going to assume that when you say that you are setting the poll timeout to 500ms, you are setting the pollTimeout variable to 500. That would be wrong. For a 500ms timeout, the pollTimeout variable must be set to 500000. If you do context.Poll (..., 500), it is interpreted as 500μs and is internally rounded to 0ms.

I have verified on my own system that passing 500 per poll will result in a CPU utilization of between 90 and 100%. Setting the value to anything over 1000 makes CPU usage much less, and for 500000 (500ms) it should be negligible.



Anyway, please update the sample code before initializing the pollTimeout variable. If I'm completely out of the database, then at least it will prevent other potential responders from going down this path.

+4


source






More articles:


All Articles