Đừng đoán — hãy đo trước. Sự chậm có thể đến từ client, network, server, hoặc database. Một cách tiếp cận có phương pháp sẽ tìm ra thời gian đi đâu, rồi sửa yếu tố đóng góp lớn nhất thay vì tối ưu lung tung.
Đừng đoán — hãy đo trước. Sự chậm có thể đến từ client, network, server, hoặc database. Một cách tiếp cận có phương pháp sẽ tìm ra thời gian đi đâu, rồi sửa yếu tố đóng góp lớn nhất thay vì tối ưu lung tung.
1. ĐO → thời gian tiêu ở đâu? client render, network, server, DB?
2. TÁI HIỆN → xác nhận lỗi xảy ra ổn định (cùng endpoint, payload, user)
3. TRACE → dùng APM/distributed traces để tìm span chậm
4. KIỂM TRA THAY ĐỔI GẦN ĐÂY → deploy, config, traffic, dữ liệu tăng
5. CÔ LẬP → từng lớp một, thu hẹp về một component
6. SỬA yếu tố đóng góp lớn nhất → đo lại để xác nhận
Dùng tab Network/Performance của trình duyệt và timing phía server để tách tổng thời gian. Một cách phân rã hữu ích:
Tổng 1200ms =
DNS/connect 20ms
server TTFB 900ms ← bottleneck nằm ở phía server
download 80ms
client render 200ms
Nhìn vào percentile, không phải trung bình: p50 (user điển hình) so với p99 (trường hợp tệ nhất). p50 nhanh nhưng p99 chậm cho thấy vấn đề thi thoảng — lock contention, cache nguội, một DB replica chậm, hoặc GC pause — chứ không phải vấn đề đồng đều.
Công cụ APM (traces) cho thấy chính xác thời gian đi đâu bên trong một request:
GET /orders 950ms
├─ auth check 10ms
├─ SELECT orders 30ms
└─ loop: SELECT user per order 900ms ← N+1 query, nguyên nhân thực
Trace chỉ thẳng vào lời gọi gây vấn đề. Rồi kiểm tra thay đổi gần đây — một deploy, một index thiếu, hoặc dữ liệu tăng 10x thường giải thích một regression đột ngột.
Đoán mò làm lãng phí hàng giờ tối ưu sai lớp. Đo trước, trace span chậm, và nhìn vào p50 vs p99 biến một câu "nó chậm" mơ hồ thành một nguyên nhân cụ thể, sửa được — và đo lại chứng minh bản sửa thực sự hiệu quả.