Home/ Questions/Q 7831279
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T11:39:18+00:00

Our project needs to do TCP packet load balance to node.js . The proposal

  • 0

Our project needs to do TCP packet load balance to node.js .

The proposal is： (Nginx or LVS) + Keepalived + Node Cluster

enter image description here

The questions:

  1. The high concurrent client connections to TCP server needs to be long-lived. Which one is more suitable, Nginx or LVS?
  2. We need to allocate different priority levels for node master on the Master server (the priority of localhost server will be higher than the remote servers). Which one can do this, Nginx or LVS?
  3. Whose CPU utilization is smaller and the throughput is higher, Nginx or LVS?
  4. Any recommended documents for performance benchmarking/function comparison between Nginx and LVS?

At last, we wonder whether our proposal is reasonable. Is there any other better proposals or component to choose?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’m assuming you do not need nginx to server static assets, otherwise LVS would not be an option.

    1) nginx only supports TCP via 3rd party module https://github.com/yaoweibin/nginx_tcp_proxy_module If you don’t need a webserver, I’d say LVS is more suitable, but see my additional comment at the end of the #’d answers.

    2) LVS supports priority, nginx does not.

    3) Probably LVS: nginx is userland, LVS kernel.

    4) Lies, Damned Lies and Benchmarks. You have to simulate your load on your equip, write a node client script and pound your setup.

    We are looking at going all node from front to back with up https://github.com/LearnBoost/up Not in production yet, but we are pursuing this route for the following reasons:

    1) We also have priority requirements, but they are custom and change dynamically. We are adjusting priority at runtime and it took us less than an hour to program node to do it.

    2) We deploy a lot of code updates and up allows us to do it without interrupting existing clients. Because you can code it to do anything you want, we can spin up brand new processes to handle new connections and let the old ones die when existing connections are all gone.

    3) We can see everything because we push any metric we want to see into a redis server.

    I’m sure it’s not the most performant per process/server, but the advantage of having so much programatic control is worth it, and scale out has the advantage of more redundancy so we are not looking at squeezing the last bit of performance out of the stack.

    I just checked real quick to see if I could copy/paste a bunch of code, but we are rapidly coding it and it has a lot of references to stuff that would not be suitable for public consumption.

    • 0