Bạn có biết?
Ứng dụng chậm dần theo thời gian, RAM phình to tới mức bị kill mỗi đêm. Bạn đoán mò: "chắc do thư viện X". Profiling thay phán đoán bằng dữ liệu: CPU profile cho biết hàm nào tốn thời gian, heap snapshot cho biết object nào ăn bộ nhớ, event loop lag cho biết có gì đang chặn. Bài này: quy trình 5 bước tìm và xử lý nút thắt hiệu năng Node.js.
Bước 1: Đo trước khi tối ưu
Nguyên tắc vàng: đừng tối ưu theo cảm giác. Đo bằng: p99 latency (xem bài Monitoring), event loop lag, CPU/memory metrics. Nếu p99 đã dưới 200ms và CPU dưới 60% — đừng đụng vào, tối ưu sớm là nguồn gốc của bug.
- Latency cao + CPU thấp → nút thắt ở I/O (DB query, network, lock)
- Latency cao + CPU cao → code CPU-bound (JSON lớn, crypto, vòng lặp)
- Memory tăng mãi → memory leak (object giữ tham chiếu)
- Event loop lag → có thao tác đồng bộ nặng chặn luồng
Bước 2: CPU profile — hàm nào tốn thời gian
# Chạy với inspector, bật profiling từ đầu
node --cpu-prof --cpu-prof-dir=./profiles src/index.js
# Hoặc bật/ tắt khi đang chạy qua signal
kill -SIGUSR1 # bật inspector
# rồi dùng Chrome DevTools: chrome://inspect → profile
# Phân tích file .cpuprofile bằng Clinic.js
npx clinic flame -- node src/index.js
# mở browser xem flamegraph — đốm đỏ to = hàm nóng
Flamegraph cho bạn thấy ngay: hàm X chiếm 40% CPU. 80% thời gian bạn sẽ thấy thủ phạm quen thuộc: JSON.stringify payload khổng lồ, bcrypt.compare bị gọi quá nhiều, vòng lặp xử lý mảng lớn, hoặc crypto không cần thiết.
Bước 3: Heap snapshot — memory leak ở đâu
# Chụp heap 3 lần, cách nhau 30 phút, so sánh
kill -SIGUSR2 # Node tự ghi heap snapshot ra file
# hoặc dùng --heapsnapshot-signal=SIGUSR2 khi khởi động
# So sánh 2 snapshot bằng Chrome DevTools: Memory → Load → Comparison
# object nào tăng không phanh = leak
Thủ phạm leak kinh điển trong Node.js:
0 bình luận
Đang tải bình luận...
Để lại bình luận