คุณ profile และ optimize ประสิทธิภาพของ Node.js อย่างไร?

Question

Accepted Answer

การ optimize ประสิทธิภาพของ Node เริ่มต้นด้วยการ **วัด** เพื่อหา bottleneck ที่แท้จริง — ไม่ใช่การเดา คุณ profile การใช้ CPU, event loop และหน่วยความจำ แล้วจึงใช้การแก้ไขที่ตรงจุด กฎทองคือ profile ก่อน แล้ว optimize สิ่งที่ช้าจริง ๆ

## เครื่องมือ profiling

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

สิ่งเหล่านี้เผยให้เห็น *ว่า* เวลาหายไปที่ไหน — flame graph แสดงว่าฟังก์ชันใดครอบงำ CPU เพื่อให้คุณ optimize สิ่งที่ถูกต้อง

## ปัญหาเฉพาะของ Node อันดับ 1: event loop ที่ถูกบล็อก

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

เพราะ Node เป็น single-threaded สำหรับ JS การ operation แบบ synchronous ที่ยาวนานใด ๆ จะบล็อกทุกอย่าง ให้ monitor **event-loop lag** (เช่น `monitorEventLoopDelay` ของ `perf_hooks`); lag ที่เพิ่มขึ้นหมายความว่ามีบางสิ่งกำลังบล็อก loop อยู่ แก้ด้วยการย้ายงาน CPU ไปยัง **worker threads** หรือ queue

## การ optimize ที่พบบ่อย (ใช้หลังจาก profiling ชี้มาแล้ว)

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

## บ่อยครั้งเป็นที่ database ไม่ใช่ 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.
```

## Benchmark เพื่อยืนยัน

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

วัดก่อนและหลังการเปลี่ยนแปลงแต่ละครั้งเพื่อยืนยันว่า optimization นั้นช่วยได้จริง

## ทำไมจึงสำคัญ

งานด้านประสิทธิภาพมีประสิทธิผลก็ต่อเมื่อ **ขับเคลื่อนด้วยการวัด** — การ optimize ผิดจุดทำให้เสียแรงเปล่าและเพิ่มความซับซ้อน

การรู้วิธี profile (clinic.js/flame graph/DevTools สำหรับ CPU, การ monitor event-loop lag, การวิเคราะห์ heap) ช่วยให้คุณค้นหา bottleneck ที่แท้จริง ซึ่งใน Node มักเป็น event loop ที่ถูกบล็อก (แก้ด้วย worker threads) หรือ database query ที่ช้า (N+1, ขาด index — มักเป็นต้นเหตุที่แท้จริง)

เมื่อรวมกับ caching, streaming, parallelism และ pooling — และการยืนยันด้วย load test — วินัยแบบวัดแล้วค่อยแก้นี้คือสิ่งที่เปลี่ยน service ที่อืดให้เป็น service ที่เร็วและ scale ได้