Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question on Nexus CPU usage #204

Open
mch12345 opened this issue Oct 10, 2019 · 1 comment
Open

Question on Nexus CPU usage #204

mch12345 opened this issue Oct 10, 2019 · 1 comment
Labels

Comments

@mch12345
Copy link

Hello,

I did few tests using Nexus with the following configuration :

  • Nexus launched on a master machine

  • A subscriber coded in Python on the master machine aswell

  • A Publisher coded in Java on a remote host

The Publisher sending a big load of data as frequently as he can, to try to flood the Nexus.

I noticed that the Nexus was dropping events because it was receiving too many requests,but when I checked the CPU usage on the master machine, only two CPUs were used at the maximum of their capabilities. I felt like the subscriber and the Nexus were attached to one CPU at a time. I was surprised as I thought that Nexus should use the maximum of the machine's capability it's launched on.

In addition to that, I got completely different results when I attempt to run the same test on a single machine, with the Nexus, the publisher, and the subscriber being launched on the master.
In this case, all the master machine CPUs were used at the maximum of their capabilities.

Have you ever encountered or heard about such behavior?
Is there a setting in the nexus configuration file to define to avoid this problem?

Thank you in advance

@gammazero
Copy link
Owner

In the first case, only two goroutines in nexus are doing the work: the client handler, and the broker.
The client handler reads/decodes the incoming message, then hands the message off to the broker for routing. The broker looks up the destination client and writes to that client's outbound channel. If the channel is full/blocked, then the message is dropped. You are probably seeing all the work being done by the handler goroutine for the publisher handling the incoming messages from the publisher. If there is only one publisher, and it cannot send to subscriber(s), then it will only drive one core. If you try the same experiment with multiple publishers, you will should see additional cores used for the additional publishers.

In the test with everything running on the same machine, the clients are going to be running across additional cores.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants