Introduction: The Challenge of High-Concurrency WebSockets

In modern real-time applications—ranging from financial trading dashboards to live chat systems and collaborative tools—maintaining a massive number of concurrent connections is a core requirement. Node.js, built on the V8 JavaScript engine and utilizing an asynchronous, event-driven architecture, is inherently well-suited for I/O-intensive tasks like WebSockets. However, out-of-the-box Linux virtual private servers (VPS) are not configured for massive scale. By default, a standard Linux kernel restricts resource allocation to protect the system from being overwhelmed by a single process.

When attempting to scale a Node.js application to 100,000 concurrent WebSockets connections, you will quickly encounter system bottlenecks such as the 'Too many open files' error, connection drops, and high latency. To unlock the true potential of your infrastructure, you must perform deep Linux kernel tuning. This technical guide explores the exact parameter adjustments, network stack optimizations, and application-level configurations required to safely reach the 100k concurrent connection milestone.

---

Understanding the Bottlenecks: Files and the Network Stack

To optimize a system, you must first understand its limitations. In Linux, everything is a file. Every incoming TCP connection established via a WebSocket allocates a file descriptor (FD). If your operating system limits a single process to 1,024 file descriptors (a common default), your application will fail long before reaching its target. Furthermore, the networking subsystem manages buffers, queues, and connection states that must be scaled up to prevent packet loss under heavy load.

---

Step 1: Overcoming File Descriptor Limits

The first critical barrier is the system-wide and per-user limits on file descriptors. We must configure both the absolute system maximum and the specific limits allocated to the user running the Node.js process.

System-Wide Configuration

To increase the maximum number of file descriptors the entire operating system can allocate, append the following line to /etc/sysctl.conf:

fs.file-max = 2097152

This expands the limit to over 2 million files, ensuring the OS has plenty of headroom for our 100,000 connections plus standard system processes.

User-Level Configuration

Next, we modify the security limits to permit the specific Node.js user account to open at least 100,000 files. Edit the /etc/security/limits.conf file and add the following rules:

nodejs soft nofile 150000
nodejs hard nofile 150000

The soft limit is the value the kernel enforces for the session, while the hard limit acts as a ceiling that the user cannot exceed without root privileges. Setting these to 150,000 provides a 50% buffer above our 100k target.

---

Step 2: Advanced Network Stack (sysctl) Optimization

The heart of kernel tuning lies within the sysctl parameters, which control the behavior of the Linux TCP/IP stack. To apply these configurations, add the following lines to /etc/sysctl.conf and run sudo sysctl -p to commit the changes dynamically.

1. Enhancing the TCP Backlog Queues

When thousands of connections hit the server simultaneously, they enter a queue before being accepted by Node.js. If the queue is too small, connections are dropped.

net.core.somaxconn = 65535: Increases the maximum backlog of completely established sockets waiting to be accepted.
net.ipv4.tcp_max_syn_backlog = 65535: Expands the queue for half-open connections (TCP SYN packets received, but ACK not yet returned).

2. Optimizing Memory Allocations for TCP Buffers

Each network socket requires memory for read and write buffers. If buffers are too large, 100,000 connections will exhaust system RAM. If they are too small, network throughput drops. We must define efficient min, default, and max memory bounds (measured in bytes):

net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216

By keeping the minimum and default settings relatively low, the kernel can conserve memory for inactive WebSockets while still scaling up to 16MB per socket if a specific connection requires heavy data transfer.

3. Speeding Up Connection Reuse

WebSockets connections are long-lived, but when they disconnect, they temporarily enter a TIME_WAIT state. To prevent thousands of dead connections from exhausting available local ports, optimize the following parameters:

net.ipv4.tcp_tw_reuse = 1: Allows the kernel to safely reuse TIME_WAIT sockets for new connections when safe from a protocol viewpoint.
net.ipv4.tcp_fin_timeout = 15: Lowers the amount of time a socket spends in the FIN-WAIT-2 state from the default 60 seconds down to 15 seconds, freeing up resources much faster.

---

Step 3: Expanding Local Port Range

By default, Linux limits outbound or ephemeral connections to a restricted port range. While a WebSocket server listens on a single incoming port (e.g., 80 or 443), tracking the unique combinations of source IP, source port, destination IP, and destination port requires sufficient port availability on the host system. Expand the ephemeral port range by modifying:

net.ipv4.ip_local_port_range = 1024 65535

This modification provides over 64,000 local ports per unique IP address, drastically reducing local port exhaustion errors.

---

Step 4: Tailoring Node.js for High Concurrency

Kernel tuning handles the infrastructure layer, but your Node.js application layer must also be optimized to process 100,000 concurrent loops efficiently.

Increasing V8 Heap Memory

Managing the state of 100k connections requires substantial memory overhead within JavaScript. Ensure your Node.js process has access to adequate RAM by raising the V8 engine heap size using the environment flag:

node --max-old-space-size=4096 server.js

This allows the V8 engine to utilize up to 4GB of RAM before triggering aggressive, blocking garbage collection cycles.

Leveraging Node.js Cluster Module

Node.js runs on a single thread by default. A single CPU core cannot easily handle the cryptographic overhead (TLS/SSL) and event loop processing for 100,000 active WebSockets. Utilize the native cluster module or a process manager like PM2 to spin up one worker process per available CPU core:

pm2 start server.js -i max

By running cluster workers, incoming traffic is load-balanced across multiple CPU cores, scaling your execution capacity horizontally across your VPS hardware resources.

---

Conclusion: Testing and Monitoring Your Scale

Achieving 100,000 concurrent WebSockets connections requires a holistic approach that unites operating system constraints with application architecture. By lifting file descriptor ceilings, refining TCP buffer sizes, speeding up socket recycling, and maximizing Node.js runtime parameters, your VPS turns into a high-throughput engine capable of extreme scale.

Before moving to a production environment, always validate your setup using open-source load-testing utilities like Artillery or Autocannon configured on separate benchmarking client servers. Monitor your server's health using tools like htop, ss -s (to track socket counts), and netstat to ensure memory utilization remains predictable and your event loop latency stays low under maximum load.

Deep Linux Kernel Tuning: Scaling Node.js VPS to 100,000 Concurrent WebSockets