goodgo-platform/load-tests/results/BASELINE-REPORT.md

Báo Cáo Kiểm Thử Tải K6 Baseline

Ngày: 2026-04-09 Môi trường: Dev cục bộ (macOS, localhost:3001) Phiên bản K6: v1.7.1 Trạng thái API: Đang chạy (NestJS chế độ dev)

Tóm Tắt Điều Hành

Tất cả bốn bộ kiểm thử K6 đã thực thi thành công. Các chỉ số độ trễ rất tốt trên tất cả các endpoint — nằm trong ngưỡng SLA cho phép. Tuy nhiên, tính đúng đắn về mặt chức năng bị ảnh hưởng bởi các giới hạn của môi trường dev (các endpoint xác thực trả về 500 do sự cố cơ sở dữ liệu/dependency, Typesense không khả dụng cho tìm kiếm).

Phát hiện chính: Server API xử lý concurrency cao tốt ở tầng mạng/framework. Hiệu năng logic nghiệp vụ thực tế cần được xác nhận lại khi các dependency backend (PostgreSQL + Prisma, Typesense, VNPay) đã hoạt động đầy đủ.

Ngưỡng SLA (từ cấu hình)

Chỉ số	Mục tiêu	Trạng thái
p50 latency	< 200ms	ĐẠT (tất cả bộ kiểm thử < 3ms)
p95 latency	< 500ms	ĐẠT (tất cả bộ kiểm thử < 6ms)
p99 latency	< 1000ms	ĐẠT (tất cả bộ kiểm thử < 19ms)
Error rate	< 1%	KHÔNG ĐẠT (auth/listings/payments trả về 500)

Kết Quả Chi Tiết

1. Bộ Kiểm Thử Auth (auth.js)

Chỉ số	Giá trị
Peak VUs	100
Duration	2m (ramp 30s → sustain 1m → ramp-down 30s)
Total Requests	4.572
Throughput	37,6 req/s
p50 latency	2,12ms
p95 latency	5,24ms
p99 latency	9,12ms
Error Rate	100% (HTTP 500 — lỗi server nội bộ)
Data Received	7,6 MB (62 kB/s)

Ghi chú:

• Endpoint đăng ký (POST /auth/register) trả về 500 — có thể do sự cố kết nối Prisma/DB trong môi trường dev
• Các bài kiểm thử đăng nhập không thể chạy (không có người dùng trong pool do đăng ký thất bại)
• Baseline độ trễ ổn định — tầng framework + routing phản hồi nhanh

2. Bộ Kiểm Thử Listings (listings.js)

Chỉ số	Giá trị
Peak VUs	500
Duration	3m (ramp 30s → sustain 2m → ramp-down 30s)
Total Requests	56.347
Throughput	311,7 req/s
p50 latency	0,55ms
p95 latency	2,37ms
p99 latency	4,24ms
Error Rate	100% (HTTP 500)
Data Received	68 MB (377 kB/s)

Ghi chú:

• Throughput cao nhất trong tất cả các bộ kiểm thử (311 req/s ở 500 VUs)
• p50 dưới mili-giây cho thấy phản hồi lỗi rất nhanh
• Endpoint chi tiết không được kiểm thử (không có listings nào được tạo trong bước setup)
• Cần kiểm thử lại với dữ liệu DB đã được seed để có benchmark thực tế

3. Bộ Kiểm Thử Search (search.js)

Chỉ số	Giá trị
Peak VUs	200
Duration	3m (ramp 30s → sustain 2m → ramp-down 30s)
Total Requests	18.743
Throughput	103,7 req/s
p50 latency	1,27ms
p95 latency	2,59ms
p99 latency	4,57ms
Error Rate	0% (phản hồi 503 được coi là chấp nhận được)
Data Received	155 MB (856 kB/s)

Ghi chú:

• Tìm kiếm văn bản: p95 = 2,65ms, Tìm kiếm địa lý: p95 = 2,55ms
• Tỷ lệ lỗi HTTP 0% (503 từ Typesense là dự kiến trong môi trường dev khi không chạy Typesense)
• Xác thực phản hồi thất bại (không có trường data trong các phản hồi 503) — dự kiến
• Đã sửa sự cố tương thích K6 với URLSearchParams trong lần chạy kiểm thử này

4. Bộ Kiểm Thử Payments (payments.js)

Chỉ số	Giá trị
Peak VUs	50
Duration	2m (ramp 30s → sustain 1m → ramp-down 30s)
Total Requests	20
Throughput	0,17 req/s
p50 latency	1,31ms
p95 latency	5,76ms
p99 latency	18,77ms
Error Rate	100% (đăng ký trong bước setup thất bại)
Data Received	33 kB

Ghi chú:

• Số lượng request rất thấp (20) vì bước setup đăng ký người dùng thất bại
• Không có auth token, các VU thanh toán thoát ngay lập tức
• p99 ở mức 18,77ms là cao nhất trong các bộ kiểm thử — cho thấy endpoint thanh toán có overhead xử lý nhiều hơn
• Cần auth hoạt động trước khi có thể thực hiện benchmark thanh toán có ý nghĩa

Các Điểm Nghẽn Được Xác Định

1. Auth/Đăng ký (Nghiêm trọng): POST /auth/register trả về 500 — chặn tất cả các luồng kiểm thử yêu cầu xác thực. Nguyên nhân gốc rễ: có thể Prisma client không kết nối được với PostgreSQL hoặc thiếu trạng thái migration.
2. Typesense Không Khả Dụng: Search trả về 503 — dự kiến trong môi trường dev cục bộ khi không có service Typesense. Các bài kiểm thử xử lý đúng điều này với các kiểm tra dự phòng.
3. Tương Thích K6: search.js sử dụng URLSearchParams (không có trong runtime K6) — đã sửa bằng cách thay thế bằng string interpolation.
4. Payment Gateway: Tích hợp VNPay trả về lỗi trong môi trường dev — dự kiến, các bài kiểm thử chấp nhận 502/503 là hợp lệ.

Benchmark Baseline (Tầng Framework)

Các con số này thể hiện hiệu năng tầng framework NestJS + routing (phản hồi lỗi), không phải logic nghiệp vụ đầy đủ:

Nhóm Endpoint	p50	p95	p99	Max RPS
Auth (register/login)	2,12ms	5,24ms	9,12ms	~38/s
Listings (search/detail)	0,55ms	2,37ms	4,24ms	~312/s
Search (text/geo)	1,27ms	2,59ms	4,57ms	~104/s
Payments (create/list)	1,31ms	5,76ms	18,77ms	~0,2/s*

*Throughput của Payments thấp bất thường do lỗi setup.

Khuyến Nghị

1. Chạy lại với backend đầy đủ: Thiết lập PostgreSQL + seed dữ liệu, khởi động Redis, và tùy chọn Typesense trước khi chạy lại để có benchmark ở mức logic nghiệp vụ.
2. Tích hợp CI: Kết nối workflow GitHub Actions load-test.yml để chạy trên môi trường staging với dữ liệu thực.
3. Cảnh báo hồi quy hiệu năng: Đặt ngưỡng trong CI — fail pipeline nếu p95 > 500ms hoặc error rate > 5%.
4. Dashboard Grafana: Xuất kết quả K6 sang Grafana Cloud hoặc InfluxDB để theo dõi lịch sử.
5. Tăng VUs cho payments: Khi auth hoạt động, kiểm thử payments ở 100+ VUs để tìm điểm nghẽn của gateway.

Các Tệp Được Tạo

• load-tests/results/auth.json — Dữ liệu JSON thô từ K6
• load-tests/results/listings.json — Dữ liệu JSON thô từ K6
• load-tests/results/search.json — Dữ liệu JSON thô từ K6
• load-tests/results/payments.json — Dữ liệu JSON thô từ K6