Node ਕਾਰਗਿਆਲੀ ਦਾ ਅਨੁਕੂਲਨ ਮਾਪਣ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਤਾਂ ਜੋ ਅਸਲ ਗਲੀ ਦਾ ਪਤਾ ਲੱਗ ਸਕੇ — ਕਦੀ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾਉ। ਤੁਸੀਂ CPU ਵਰਤੋਂ, ਇਵੈਂਟ ਲੂਪ ਅਤੇ ਮੈਮੋਰੀ ਨੂੰ ਪ੍ਰੋਫਾਈਲ ਕਰਦੇ ਹੋ, ਫਿਰ ਟੀਕੇ ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ। ਸੋਨੇ ਦਾ ਨਿਯਮ: ਪਹਿਲਾਂ ਪ੍ਰੋਫਾਈਲ ਕਰੋ, ਉਹ ਚੀਜ਼ ਅਨੁਕੂਲ ਕਰੋ ਜੋ ਅਸਲ ਵਿੱਚ ਸੁਸਤ ਹੈ।
node --prof app.js
node --prof-process isolate-*.
npx clinic doctor -- node app.js
npx clinic flame -- node app.js
node --inspect app.js
ਇਹ ਦਿਖਾਉਂਦੇ ਹਨ *ਕਿ ਸਮਾਂ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ — ਇੱਕ flame graph ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਫੰਕਸ਼ਨ CPU ਨੂੰ ਦਬਾਉਂਦੀ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਸਹੀ ਚੀਜ਼ ਨੂੰ ਅਨੁਕੂਲ ਕਰਦੇ ਹੋ।
// ❌ synchronous CPU-heavy work blocks ALL request handling
function handler(req, res) {
const result = heavyComputation(); // freezes the event loop → every request stalls
res.json(result);
}
ਕਿਉਂਕਿ Node JS ਲਈ ਸਿੰਗਲ-ਥ੍ਰੈਡ ਹੈ, ਕੋਈ ਵੀ ਲੰਬੀ ਸਿੰਕ੍ਰੋਨਸ ਓਪਰੇਸ਼ਨ ਸਭ ਕੁਝ ਬਲਾਕ ਕਰਦੀ ਹੈ। ਇਵੈਂਟ-ਲੂਪ lag ਨੂੰ ਮਨੀਟਰ ਕਰੋ (ਮਤਲਬ perf_hooks monitorEventLoopDelay); ਵੱਧਦਾ lag ਮਤਲਬ ਕਿਸ ਚੀਜ਼ ਲੂਪ ਨੂੰ ਬਲਾਕ ਕਰ ਰਹੀ ਹੈ। CPU ਕੰਮ ਨੂੰ worker threads ਜਾਂ ਕਤਾਰ ਵਿੱਚ ਅਸਲ ਕਰਕੇ ਠੀਕ ਕਰੋ।
✓ Fix N+1 database queries — the most common real bottleneck (batch/join instead)
✓ Add caching (in-memory/Redis) for repeated expensive operations
✓ Add database indexes for slow queries
✓ Use streams for large data instead of buffering it all in memory
✓ Parallelize independent async ops with Promise.all (avoid await waterfalls)
✓ Offload CPU-bound work to worker threads (keep the event loop free)
✓ Use connection pooling for DB/HTTP
✓ Enable gzip/brotli compression for responses
Many "Node is slow" problems are actually slow DB queries (N+1, missing indexes)
or external API latency — profiling reveals this so you fix the real cause.
npx autocannon http://localhost:3000 # measure requests/sec, latency before & after
ਹਰ ਤਬਦੀਲੀ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਮਾਪੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਤਸਦੀਕ ਕਰ ਸਕੋ ਕਿ ਅਨੁਕੂਲਨ ਸਮੱਗਰੀ ਵਿੱਚ ਸਫ਼ਲ ਰਿਹਾ।
ਕਾਰਗਿਆਲੀ ਦਾ ਕੰਮ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸਿਰਫ ਤਦ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਮਾਪ ਦ੍ਵਾਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ — ਗਲਤ ਚੀਜ਼ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨਾ ਪ੍ਰਯਾਸ ਬਰਬਾਦ ਕਰਦਾ ਹੈ ਅਤੇ ਗੁੰਝਲਾਫੁਲਤਾ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ।
ਇਹ ਜਾਣਨਾ ਕਿ ਕਿਵੇਂ ਪ੍ਰੋਫਾਈਲ ਕਰਨਾ ਹੈ (clinic.js/flame graphs/DevTools CPU ਲਈ, ਇਵੈਂਟ-ਲੂਪ lag ਮਨੀਟਰਿੰਗ, heap ਵਿਸ਼ਲੇਸ਼ਣ) ਤੁਹਾਨੂੰ ਅਸਲ ਗਲੀਆਂ ਲੱਭਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜੋ Node ਵਿੱਚ ਅਕਸਰ ਇੱਕ ਬਲਾਕ ਇਵੈਂਟ ਲੂਪ (worker threads ਨਾਲ ਠੀਕ ਕਰੋ) ਜਾਂ ਸੁਸਤ ਡਾਟਾਬੇਸ ਸਵਾਲ ਹਨ (N+1, ਗੁਮ ਕਰਡ — ਅਕਸਰ ਪ੍ਰਲੋਭਨ)।
Caching, streaming, parallelism ਅਤੇ pooling — ਅਤੇ ਲੋਡ ਟੈਸਟ ਨਾਲ ਪ੍ਰਮਾਣਿਤ — ਇਸ ਮਾਪ-ਤਦ-ਠੀਕ ਅਨੁਸ਼ਾਸਨ ਨਾਲ ਜੋੜਿਆ ਗਿਆ ਇਹ ਹੈ ਜੋ ਇੱਕ ਸੁਸਤ ਸਰਵਿਸ ਨੂੰ ਇੱਕ ਤੇਜ਼, ਸਕੇਲੇਬਲ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।