Answer the question
In order to leave comments, you need to log in
Balancer - NodeJS or Nginx?
Now we have the following structure:
Nginx routes a certain request mask to the node cluster through one socket, the node itself is engaged in balancing.
Interested in the experience of people who, for one reason or another, abandoned the balancer built into the cluster and transferred this function to nginx. Are there any pitfalls here, what problems did you encounter?
In my case, I want to have more options for setting up balancing, in particular ip_hash and least_connect. At the same time, I’m not going to completely abandon the cluster (via pm2), it has a number of useful goodies that are not advisable to reinvent.
It is interesting to hear if someone carried out load firing on such an architecture.
Naturally, the cluster in this case is transferred to the NODE_SHED_POLICY=none mode
Answer the question
In order to leave comments, you need to log in
So for the story:
There is not much difference, in terms of performance, when using the Nginx vs. NodeJS balancer.
We compared our old strong-cluster-control architecture with NodeJS balancing and our new luster-based architecture with Nginx balancing.
In both cases, a cluster was raised on cpu-1 processes (in this case, 32-1).
In the case of luster, each process listens to its unix socket, balancing inside the node is disabled. Nginx created an upstream for these same 31 sockets with least_connect balancing.
luster was used as a ready-made solution that supports saving the worker index when it is restarted, its other features were not used in the main tests.
In firing with a constant load on a real project, slight deviations in the consumption of the system and user CPU were noticed both in one direction and in the other.
In failure shooting, stability increased by 5-10%.
The application under test is a stateless middleware with predominantly asynchronous operations, the idle period in one stack is no more than 5 ms. The application does not currently render templates.
For applications with heavy synchronous operations (with a stack idle period of more than 50ms), advice was received to use the following architecture:
We still raise the cluster on cpu-1, but configure the luster for a smaller number of groups, for example, 4 workers in each group, i.e. e. 4 workers will listen on the same socket.
We still disable balancing in the node. We get a preliminary balancing of least_connect using Nginx and additional balancing using the system, which will make a choice based on the readiness of the process to read from the socket.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question