Post

Node.js doesn't have a predictive way to manage traffic spikes, so over-provisioning for peak loads isn't optimized for the stable periods that follow. We've all faced this issue. This is why Platformatic is simplifying multithreading in our Node.js app server. 🧵 https://buff.ly/48yJoHD

Node.js applications are usually deployed as single-threaded: ↳Each instance operates as a single process. ↳Organizations overprovision to handle traffic spikes. ↳This leads to wasted resources and increased costs.

↳Additionally, heavy computations can block the event loop, causing performance and user experience issues.

What’s clear is that we need to rethink our approach to infrastructure. This is why Platformatic’s Watt app server now supports service replication. By starting multiple workers, you can now fully utilize all the CPU cores available on your server, providing the best possible user experience.

Most importantly, this is all done without requiring any code changes on your part. What does this mean for your application’s performance? Hint: it’s great news.

As an example, let’s analyze a basic Next.js application running within Watt. *This test was conducted on an Apple MacBook Pro with an M1 Max chip.

When subjected to 100 connections using autocannon over a span of 10 seconds, the system produced the following performance metrics:

Upon examining the top data, we found that only 3 out of the 10 available cores were actually utilized. We then repeated the test, increasing the number of `workers` to 2, and here are the results:

Finally, we repeated the test, this time using 3 workers for the service.

What were the results? • 1 Worker: P99 latency 309 ms; 5k requests in 10s • 2 Workers: P99 latency 197 ms; 10k requests in 10s • 3 Workers: P99 latency 161 ms; 11k requests in 10s

Upon reviewing the top data once more, we found that all 10 CPU cores of the machine were fully utilized.