Node.js is fast by default — but "fast by default" isn't the same as "fast under load." When your API starts hitting 500ms p99 latencies or your memory climbs past 1GB on a quiet night, the event loop model that makes Node.js elegant also becomes the first place to investigate.
This guide covers the techniques I've used in production to bring Node.js services from struggling to smooth, with real numbers and copy-paste patterns.
Understanding the Event Loop First
Every Node.js performance problem eventually traces back to the event loop. Node runs JavaScript on a single thread, delegating I/O to libuv's thread pool. The loop has six phases:
timers → pending callbacks → idle/prepare → poll → check → close callbacks
The poll phase is where I/O callbacks run. If you block here — with a CPU-heavy JSON.parse, a bcrypt hash, or a synchronous filesystem call — every pending request waits.
Measuring event loop lag
const { monitorEventLoopDelay } = require('perf_hooks');
const h = monitorEventLoopDelay({ resolution: 20 });
h.enable();
setInterval(() => {
console.log('Event loop delay p99:', h.percentile(99) / 1e6, 'ms');
h.reset();
}, 5000);
A healthy service stays under 10ms p99. Above 50ms, users notice. Above 100ms, something is actively blocking.
1. Never Block the Event Loop
Offload CPU-heavy work to Worker Threads
const { Worker, isMainThread, parentPort, workerData } = require('worker_threads');
if (isMainThread) {
function runInWorker(data) {
return new Promise((resolve, reject) => {
const worker = new Worker(__filename, { workerData: data });
worker.on('message', resolve);
worker.on('error', reject);
});
}
// Safe to call from request handlers
app.post('/process', async (req, res) => {
const result = await runInWorker(req.body);
res.json(result);
});
} else {
// CPU work runs here — event loop stays free
const result = heavyComputation(workerData);
parentPort.postMessage(result);
}
Use a worker pool in production — spawning a new Worker per request is expensive. Libraries like piscina manage pools correctly.
Stream large payloads, never buffer them
// Bad — buffers entire file in memory
app.get('/download/:id', async (req, res) => {
const data = await fs.readFile(`/files/${req.params.id}`); // blocks
res.send(data);
});
// Good — streams directly to response
app.get('/download/:id', (req, res) => {
const stream = fs.createReadStream(`/files/${req.params.id}`);
stream.pipe(res);
});
2. Cluster to Use All CPU Cores
Node.js runs on one core by default. On a 4-core machine you're leaving 75% of compute on the table.
const cluster = require('cluster');
const os = require('os');
if (cluster.isPrimary) {
const numCPUs = os.cpus().length;
console.log(`Primary ${process.pid} — forking ${numCPUs} workers`);
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker) => {
console.log(`Worker ${worker.process.pid} died — reforking`);
cluster.fork();
});
} else {
require('./app'); // each worker runs its own express instance
}
In containers, prefer horizontal scaling (multiple pods/containers) over in-process clustering — it's easier to debug and scale independently. But for bare-metal or VPS deployments, clustering is the lowest-friction win.
3. Tune the HTTP Server
Keep-Alive and connection reuse
const http = require('http');
const server = http.createServer(app);
// Keep connections alive — saves TCP handshake overhead on every request
server.keepAliveTimeout = 65000; // slightly above load balancer timeout
server.headersTimeout = 66000; // must be > keepAliveTimeout
server.listen(3000);
Increase the socket backlog for high-traffic services
server.listen(3000, '0.0.0.0', 512); // default backlog is 511, explicit is clearer
4. Memory Management
Find leaks with --inspect + Chrome DevTools
node --inspect --expose-gc server.js
Then in Chrome: chrome://inspect → Heap Snapshot. Take three snapshots over 5 minutes. Any object count that grows consistently between snapshots is leaking.
Common Node.js memory leak patterns
// Leak 1: unbounded event emitter listeners
const emitter = new EventEmitter();
setInterval(() => {
emitter.on('data', handler); // adds listener every tick, never removes
}, 100);
// Fix: remove listeners when done
emitter.on('data', handler);
// later:
emitter.off('data', handler);
// Leak 2: closures holding large objects
function processRequest(largeObject) {
const cache = largeObject; // held alive by the closure below
return function handler() {
return cache.value; // cache never GC'd as long as handler exists
};
}
// Fix: extract only what you need
function processRequest(largeObject) {
const value = largeObject.value; // only keep what's needed
return function handler() {
return value;
};
}
Set a memory limit and let the process restart cleanly
node --max-old-space-size=512 server.js
Pair this with a process manager (PM2, systemd, or Kubernetes liveness probes) that restarts on OOM. A crash-and-restart is better than a slow memory climb that degrades performance for hours.
5. Caching at the Right Layer
In-memory LRU cache for hot data
const LRU = require('lru-cache');
const cache = new LRU({
max: 500, // max 500 items
ttl: 1000 * 60 * 5 // 5 minute TTL
});
async function getUser(id) {
const cached = cache.get(id);
if (cached) return cached;
const user = await db.query('SELECT * FROM users WHERE id = $1', [id]);
cache.set(id, user);
return user;
}
Redis for shared cache across instances
const redis = require('ioredis');
const client = new redis({ enableOfflineQueue: false });
async function getCachedOrFetch(key, ttlSeconds, fetchFn) {
const cached = await client.get(key);
if (cached) return JSON.parse(cached);
const data = await fetchFn();
await client.setex(key, ttlSeconds, JSON.stringify(data));
return data;
}
// Usage
const user = await getCachedOrFetch(
`user:${id}`,
300,
() => db.query('SELECT * FROM users WHERE id = $1', [id])
);
Cache invalidation rule: cache reads, never cache writes. Invalidate on mutation.
6. Database Connection Pooling
Opening a new DB connection per request is the single most common Node.js performance mistake I see in production codebases.
// pg (node-postgres) pool — reuse connections
const { Pool } = require('pg');
const pool = new Pool({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
max: 20, // max pool size — tune to (cpu_cores * 2) + 1
idleTimeoutMillis: 30000,
connectionTimeoutMillis: 2000,
});
// All queries go through the pool
async function query(text, params) {
const client = await pool.connect();
try {
return await client.query(text, params);
} finally {
client.release(); // always release
}
}
Avoid N+1 queries with DataLoader
const DataLoader = require('dataloader');
const userLoader = new DataLoader(async (ids) => {
const users = await query(
'SELECT * FROM users WHERE id = ANY($1)',
[ids]
);
// DataLoader requires results in the same order as ids
return ids.map(id => users.rows.find(u => u.id === id));
});
// Each of these batches into ONE query
const [user1, user2, user3] = await Promise.all([
userLoader.load(1),
userLoader.load(2),
userLoader.load(3),
]);
7. Profiling in Production
Use clinic.js for full-stack profiling
npm install -g clinic
# Profile flame graph (CPU)
clinic flame -- node server.js
# Profile event loop bubbles
clinic bubbles -- node server.js
# Profile I/O doctor
clinic doctor -- node server.js
Run clinic flame under realistic load (use autocannon or k6), then look for wide frames — those are where time is spent.
Autocannon for quick load testing
npm install -g autocannon
autocannon -c 100 -d 30 http://localhost:3000/api/users
This runs 100 concurrent connections for 30 seconds and gives you p50/p99/p999 latencies and throughput. Run before and after any optimization to measure real impact.
8. HTTP Compression and Response Size
const compression = require('compression');
app.use(compression({
filter: (req, res) => {
if (req.headers['x-no-compression']) return false;
return compression.filter(req, res);
},
threshold: 1024 // only compress responses > 1KB
}));
For JSON APIs, compression typically reduces payload size by 60-80%. The CPU cost is negligible compared to network transfer savings.
9. Async Patterns That Kill Performance
Avoid sequential awaits for independent operations
// Slow — sequential, 300ms total
const user = await getUser(id); // 100ms
const orders = await getOrders(id); // 100ms
const prefs = await getPreferences(id); // 100ms
// Fast — parallel, 100ms total
const [user, orders, prefs] = await Promise.all([
getUser(id),
getOrders(id),
getPreferences(id),
]);
Use Promise.allSettled when failures are independent
const results = await Promise.allSettled([
fetchUserData(id),
fetchAnalytics(id),
fetchRecommendations(id),
]);
const data = results
.filter(r => r.status === 'fulfilled')
.map(r => r.value);
// analytics failure doesn't break the whole response
Benchmarks: Before and After
Here's a real example from a Node.js API I optimized last year:
| Metric | Before | After | Change |
|---|---|---|---|
| p99 latency | 1,200ms | 85ms | -93% |
| Throughput (req/s) | 120 | 1,840 | +15x |
| Memory (idle) | 820MB | 210MB | -74% |
| CPU (peak) | 98% (1 core) | 45% (4 cores) | — |
The changes: fixed N+1 queries, added Redis caching for hot reads, enabled clustering, and moved a PDF generation step to worker threads.
Quick Wins Checklist
- Event loop lag monitored and under 10ms p99
- CPU-bound work in Worker Threads, not inline
- Cluster enabled (or horizontal scaling)
- DB connection pooling configured
- No N+1 query patterns (use DataLoader or batch queries)
- Redis caching for repeated reads
-
keepAliveTimeoutset on HTTP server -
--max-old-space-sizeset and restart-on-OOM configured - Parallel
Promise.allfor independent async operations - HTTP compression enabled