Bài 18. Tối ưu hiệu năng cho hàng trăm website

1. Tư duy đúng về tối ưu hiệu năng trong hệ thống lớn

Trong hệ thống có hàng trăm website và web app, tối ưu hiệu năng không phải là vắt kiệt từng mili-giây, mà là:

• Tránh nghẽn cổ chai rõ ràng.

• Phân bổ tài nguyên hợp lý.

• Giữ hệ thống ổn định khi tải tăng, không sụp đột ngột.

• Dễ kiểm soát và dễ rollback khi cần.

Nguyên tắc xuyên suốt của bài này:

Ổn định > dễ vận hành > hiệu năng lý thuyết

2. Xác định đúng vị trí cần tối ưu

Trước khi chỉnh bất kỳ tham số nào, cần hiểu Reverse Proxy đang làm gì:

• Không xử lý business logic.

• Không xử lý database.

• Không render nội dung.

Reverse Proxy chủ yếu:

• Nhận kết nối (connection handling).

• Terminate HTTPS.

• Forward request/response.

Do đó, tối ưu tập trung vào:

1. Kết nối (connections)

2. I/O mạng

3. Buffer & timeout

4. Nội dung tĩnh & nén

5. Tránh làm việc thừa

3. Tối ưu worker và connection trong Nginx

3.1. Worker processes

Trong /etc/nginx/nginx.conf:

Giải thích:

• auto = số core CPU logic.

• Phù hợp cả khi máy proxy nâng cấp CPU sau này.

3.2. Worker connections

Ý nghĩa:

• Mỗi worker có thể giữ tối đa 4096 connection.

• Tổng connection ≈ worker_processes × worker_connections.

Với proxy i3 + 8GB RAM:

• Đây là mức an toàn – dư dùng cho hàng trăm website.

4. Tối ưu keepalive và reuse kết nối

4.1. Keepalive với client

Trong http {}:

Giảm:

• Overhead tạo kết nối mới.

• Đặc biệt quan trọng khi có nhiều request nhỏ (API, AJAX).

4.2. Keepalive với backend

Trong proxy-common.conf (hoặc snippet tương đương):

Lợi ích:

• Tái sử dụng kết nối tới backend.

• Giảm tải TCP handshake cho QMS/AI.

5. Tối ưu buffer cho response lớn

5.1. Buffer proxy (khuyến nghị)

Snippet snippets/performance/buffers.conf:

Phù hợp cho:

• JSON lớn

• HTML nhiều nội dung

• Report xuất dữ liệu

5.2. Khi nào cần tăng buffer

Chỉ tăng khi:

• Log xuất hiện cảnh báo buffer.

• Có response rất lớn thường xuyên.

Không tăng buffer “cho chắc”.

6. Nén nội dung (gzip) đúng chỗ

6.1. Bật gzip cho website public

Lợi ích:

• Giảm băng thông Internet.

• Tăng tốc tải trang.

6.2. Không lạm dụng gzip cho backend nội bộ

• Backend nội bộ LAN 2.5G → không cần gzip mạnh.

• Gzip tiêu tốn CPU không cần thiết.

7. Tối ưu timeout: đủ dùng, không quá dài

7.1. Timeout cho web app

Trong proxy-webapp.conf:

Giải thích:

• Đủ cho report, batch, export.

• Không để quá dài gây treo connection vô hạn.

7.2. Không dùng timeout ngắn mặc định cho web app

Timeout mặc định (60s) dễ gây:

• 504 Gateway Timeout

• Lỗi ngẫu nhiên khó debug

8. Giới hạn upload hợp lý

8.1. Chuẩn hóa upload size

Trong proxy-webapp.conf:

Không nên:

• Đặt quá nhỏ → lỗi upload.

• Đặt quá lớn nếu không cần → rủi ro abuse.

9. Tối ưu nội dung tĩnh (nếu có)

Nếu Reverse Proxy serve file tĩnh (hiếm trong hệ thống của mình):

Lợi ích:

• Giảm log không cần thiết.

• Giảm request backend.

10. Tránh các “tối ưu giả” thường gặp

10.1. Không bật cache proxy bừa bãi

• Dễ cache nhầm nội dung động.

• Dễ lỗi session, dữ liệu người dùng.

10.2. Không chỉnh kernel/network nếu chưa có bằng chứng

• net.core.somaxconn

• tcp_tw_reuse
  → Chỉ chỉnh khi có số liệu và hiểu rõ.

11. Theo dõi để tối ưu đúng chỗ

11.1. Theo dõi CPU, RAM

11.2. Theo dõi connection

11.3. Theo dõi log lỗi

Chỉ tối ưu khi thấy dấu hiệu thực tế.

12. Checklist tối ưu hiệu năng Reverse Proxy

•  worker_processes = auto

•  worker_connections ≥ 4096

•  keepalive bật cho client và backend

•  buffer hợp lý, không quá lớn

•  gzip chỉ bật cho website public

•  timeout đủ cho web app

•  không cache bừa bãi

Kết luận

Tối ưu hiệu năng cho hàng trăm website không nằm ở:

• Tham số “bí truyền”,

• Hay cấu hình cực đoan.

Mà nằm ở:

• Thiết kế đúng vai trò Reverse Proxy,

• Loại bỏ nghẽn cổ chai rõ ràng,

• Giữ hệ thống đơn giản, dễ kiểm soát.

Với các tối ưu trong bài này, Reverse Proxy của mình:

• Gánh được hàng trăm website/web app,

• Hoạt động ổn định dưới tải tăng,

• Không trở thành điểm rủi ro trong vận hành dài hạn.