Node-suorituskyvyn optimointi alkaa mittaamisella todellisen pullon kaulan löytämiseksi — älä koskaan arvaa. Profiloit CPU-käyttöä, tapahtumalooppia ja muistia, sitten käytät kohdistettuja korjauksia. Kultainen sääntö: profiloi ensin, optimoi se, mikä on todella hidas.
node --prof app.js
node --prof-process isolate-*.
npx clinic doctor -- node app.js
npx clinic flame -- node app.js
node --inspect app.js
Nämä paljastavat minne aika menee — flame graph näyttää, mitkä funktiot hallitsevat CPU:ta, joten optimoit oikean asian.
// ❌ 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);
}
Koska Node on JS:lle single-threaded, mikä tahansa pitkä synkroninen operaatio estää kaiken. Valvo event-loop lag (esim. perf_hooks monitorEventLoopDelay)؛ kasvava lag tarkoittaa, että jotain estää loopin. Korjaa siirtämällä CPU-työ worker threadeihin tai jonoon.
✓ 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
Mittaa ennen ja jälkeen jokaisen muutoksen, jotta voit vahvistaa, että optimointi todella auttoi.
Suorituskyvyn parannus on tehokasta vain, kun se on ohjattu mittaamisella — väärän asian optimointi tuhlaa ponnisteluja ja lisää monimutkaisuutta.
Tietäminen kuinka profiloida (clinic.js/flame graphs/DevTools CPU:lle, event-loop lag-valvonta, heap-analyysi) antaa sinulle mahdollisuuden paikantaa todelliset pullonkaolat, jotka Node:ssa ovat usein estetty tapahtumalooppi (korjaa worker threadeillä) tai hitaat tietokantakyselyt (N+1, puuttuvat indeksit — usein todellinen syyllinen).
Yhdessä välimuistin, streamingin, rinnakkaiskäsittelyn ja poolingiin kanssa — ja vahvistus kuormitesteillä — tämä mittaa-sitten-optimoi-kurinalaisuus on se, mitä muuttaa hidas palvelu nopeaksi, skaalautuvaksi.