Tối ưu NGINX cho nhiều kết nối

Giới thiệu

Trong quản trị hệ thống cho WordPress, nginx thường đóng vai trò xử lý lưu lượng trước khi đến ứng dụng PHP-FPM hoặc Docker container. Tối ưu hóa cho nhiều kết nối đồng thời giúp giảm độ trễ, tăng thông lượng và cải thiện trải nghiệm người dùng. Bài viết này trình bày các nguyên tắc thực tiễn và ví dụ cấu hình cơ bản mà bạn có thể áp dụng trên máy chủ của mình.

Hiệu suất và tối ưu hóa

Để xử lý nhiều kết nối, chúng ta tập trung vào các yếu tố cốt lõi sau: số lượng worker và số kết nối mỗi worker, cơ chế gọi sự kiện (epoll trên Linux), keepalive, nén dữ liệu (gzip) và HTTP/2 khi có TLS. Các mục tiêu là tối ưu băng thông, giảm chi phí CPU và hạn chế tác động từ các nguồn lưu lượng xấu.

Cấu hình cơ bản: worker_connections và epoll

Thiết lập number of worker và cách thức theo dõi sự kiện phải căn cứ vào nguồn lực của hệ thống. Sử dụng epoll trên Linux và cho phép nhận nhiều kết nối đồng thời bằng cách tăng số lượng kết nối mỗi worker.

events {
  worker_connections <n>;       # ví dụ: thay bằng giá trị phù hợp với phần cứng
  use epoll;                    # hỗ trợ quản lý I/O hiệu quả trên Linux
  multi_accept on;               # chấp nhận nhiều kết nối đồng thời khi có sẵn
}

KeepAlive và tối ưu I/O

Keepalive giúp kết nối tiết kiệm thời gian thiết lập kết nối mới giữa client và server. Tuy nhiên, quá nhiều keepalive có thể tạo ra số lượng kết nối mở đồng thời cao:

http {
  keepalive_timeout <seconds>;   # thời gian giữ kết nối mở
  keepalive_requests <n>;        # số lượt yêu cầu tối đa trên một kết nối keepalive
  # các thiết lập khác cho tối ưu I/O
}

Gzip và HTTP/2

Nén gzip giúp giảm kích thước dữ liệu truyền tải, đặc biệt hữu ích với WordPress có nhiều tài nguyên tĩnh. HTTP/2 cho phép multiplexing, giảm thiểu thời gian tải trang khi TLS được bật. Lưu ý: HTTP/2 thường cần TLS được bật.

http {
  gzip on;
  gzip_types text/plain text/css application/json application/javascript text/xml; <!-- danh sách MIME phổ biến -->
  # http2 sẽ được bật trên TLS trong ngữ cảnh thực tế
}

Rate limit và kiểm soát lưu lượng

Giới hạn lưu lượng theo địa chỉ IP hoặc các khóa khác giúp bảo vệ máy chủ khỏi các cuộc tấn công và quá tải hợp lệ. Thiết lập hợp lý giúp duy trì hiệu suất cho người dùng hợp lệ.

http {
  limit_req_zone $binary_remote_addr zone=one:<m>m rate=<rate>;  # ví dụ, thay bằng giá trị phù hợp
  limit_req zone=one burst=<n> nodelay;

  limit_conn_zone $binary_remote_addr zone=connone:<m>m;  # giới hạn kết nối
  limit_conn connone  <n>;
}

Cách làm theo từng khía cạnh

Dưới đây là cách bạn có thể triển khai trong thực tế, với các tham số được cân nhắc dựa trên tài nguyên và lưu lượng bạn gặp phải.

1. Đánh giá tài nguyên — Xác định số lượng CPU, RAM và băng thông mạng có sẵn trước khi tăng giới hạn kết nối.
2. Thiết lập hợp lý — Sử dụng các giá trị placeholder ở trên và điều chỉnh dựa trên dữ liệu thực tế từ log và metrics.
3. Theo dõi và điều chỉnh — Theo dõi thời gian phản hồi, thặng dư CPU và số kết nối trung bình để tối ưu tiếp theo.

Đảm bảo rằng việc tối ưu hiệu suất không làm giảm tính bảo mật. Bổ sung các biện pháp bảo vệ DDoS và kiểm soát lưu lượng ở mức hợp lý để tránh bị lợi dụng.

Giám sát và đo lường

Thiết lập logging và theo dõi các chỉ số quan trọng như số kết nối đang mở, thời gian phản hồi và tỉ lệ lỗi. Dữ liệu này giúp bạn đánh giá tác động của các thay đổi và điều chỉnh cho phù hợp.

Sai lầm phổ biến và cách tránh

• Quá lạm dụng giá trị tối đa cho worker_connections mà không cân nhắc tài nguyên thực tế.
• Bỏ qua tác động của keepalive đến số lượng kết nối đồng thời.
• Không bật gzip hoặc HTTP/2 khi cần thiết và bỏ qua lợi ích của nén và multiplexing.
• Thiếu cơ chế giới hạn lưu lượng dẫn đến tấn công từ chối phục vụ hoặc quá tải máy chủ.

Checklist tối ưu NGINX cho nhiều kết nối

• Đánh giá tài nguyên hệ thống và yêu cầu lưu lượng thực tế.
• Cấu hình sự kiện với worker_connections phù hợp và sử dụng epoll.
• Thiết lập keepalive_timeout và keepalive_requests hợp lý.
• Bật gzip và xem danh sách mime-type phù hợp với tài nguyên của WordPress.
• Xem xét bật HTTP/2 cho TLS để tối ưu multiplexing.
• Cài đặt giới hạn lưu lượng và giới hạn kết nối để bảo vệ hệ thống.
• Thiết lập logging và theo dõi các chỉ số quan trọng liên tục.

Kết luận

Khi tối ưu NGINX cho nhiều kết nối, bạn cần cân bằng giữa hiệu suất và bảo mật. Hãy bắt đầu với các thiết lập căn bản có thể điều chỉnh theo thực tế, đồng thời theo dõi các chỉ số hiệu suất để tiếp tục tối ưu.

Cung cấp ví dụ thực tế cho quản trị viên hệ thống

Bài viết bao gồm các đoạn cấu hình mẫu với các tham số mang tính tham khảo. Bạn có thể sao chép và thay thế các giá trị placeholder bằng giá trị cụ thể phù hợp với hệ thống của mình.

FAQ (Câu hỏi thường gặp)

Q: Làm thế nào để quyết định giá trị worker_connections phù hợp?

A: Dựa trên số lượng kết nối đồng thời ước tính và giới hạn tài nguyên. Bắt đầu với giá trị thỏa đáng và điều chỉnh dựa trên dữ liệu thực tế từ log và metrics.

Q: Có nên bật HTTP/2 cho WordPress trên NGINX không?

A: Nếu có TLS, HTTP/2 có thể mang lại hiệu quả nhờ multiplexing và giảm độ trễ, đặc biệt với trang có nhiều tài nguyên tĩnh.

Q: Làm sao để cân bằng gzip và thời gian tải trang?

A: Bật gzip và chọn danh sách mime-type phù hợp để nén tài nguyên phổ biến mà WordPress phục vụ, tránh nén các tài nguyên đã tối ưu hoặc quá nhỏ.

Q: Những sai lầm phổ biến khi tối ưu NGINX cho nhiều kết nối?

A: Không kiểm tra tài nguyên trước khi tăng giới hạn, không theo dõi sau khi thay đổi, hoặc bỏ qua giới hạn lưu lượng có thể gây quá tải và tăng thiểu hiệu suất.