Kaip profiliuoti ir optimizuoti Node.js našumą?

Question

Accepted Answer

Node.js našumo optimizavimas pradedamas **matavimais**, siekiant rasti tikrąjį siaurą vietą — niekada neatspėjinėjant. Profiliuojate CPU naudojimą, event loop'ą ir atmintį, tada taikote tiksliyje pataisas. Auksinis dėsnis: pirmiausia profiliuokite, optimizuokite tai, kas iš tikrųjų lėta.

## Profiliavimo įrankiai

```bash
# CPU profiling — find which functions consume CPU time
node --prof app.js                    # generates a V8 profile log
node --prof-process isolate-*.log     # human-readable summary

# all-in-one diagnostics (flame graphs, event-loop, memory)
npx clinic doctor -- node app.js      # diagnoses the bottleneck type
npx clinic flame -- node app.js       # CPU flame graph (hot functions)

# the Chrome DevTools profiler
node --inspect app.js                 # then connect DevTools for CPU/memory profiles
```

Šie įrankiai atskleidžia, *kur* eina laikas — flame graph'as rodo, kurios funkcijos dominuoja CPU, todėl optimizuojate reikiamą dalį.

## Pagrindinė Node-specific problema: blokuotas event loop'as

```js
// ❌ 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);
}
```

Kadangi Node yra vienvijis JavaScript'ui, bet kuri ilga sinchroninė operacija blokuoja viską. Stebėkite **event-loop lag'ą** (pvz. `perf_hooks` `monitorEventLoopDelay`); kylantis lag'as reiškia, kad kažkas blokuoja loop'ą. Pataisykite perkeliant CPU darbą į **worker threads'us** ar eilę.

## Bendri optimizavimai (taikykite po to, kai profiliavimas juos nurodo)

```text
✓ 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
```

## Dažnai tai yra duomenų bazė, o ne Node

```text
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.
```

## Atlikite lyginamąjį testą patikrinti

```bash
npx autocannon http://localhost:3000   # measure requests/sec, latency before & after
```

Matavinkite prieš kiekvieną pokyčį ir po jo, kad patvirtintumėte, jog optimizavimas tikrai padėjo.

## Kodėl tai svarbu

Nasumo darbai yra efektyvūs tik tada, kai **nukreipti matavimais** — optimizavus netinkamą dalį, nuken­čia pastangos ir padidėja sudėtingumas.

Žinodami, kaip profiliuoti (clinic.js/flame graphs/DevTools CPU, event-loop lag'o stebėjimas, heap'o analizė), galite nustatyti tikrus siaurus vietas, kurios Node'je dažnai yra blokuotas event loop'as (pataisykite su worker threads'ais) arba lėtos duomenų bazės užklausos (N+1, trūkstantys indeksai — dažnai tikrasis kaltininkas).

Suderintas su cache'avimu, stream'ingu, lygiagretumu ir pool'avimu — ir patikrintas apkrovos testais — šis matavimo-tada-pataisymo disciplina yra tai, kas lėtą paslaugą paverčia greita, masteliuojamąja.