Tối ưu Performance Cho Nginx
Lâu lắm mình mới có thời gian viết lách tí. Lần này xin trở lại share anh em kinh nghiệm về Nginx. Cũng nhân tiện vừa fix cho đối tác, họ đang chạy production mà config để mặc định nhiều quá, dẫn tới lỗi 5xx liên tục. Mặc dù Nginx đang chạy cluster ECS trên AWS. Sau một thời gian lần sờ các thể loại utilisation với mớ logs thì nó cũng lòi ra đầu log của Nginx với nội dung: 512 worker_connections are not enough while connecting to upstream... Bingo... Thấy chỗ log này là cuộc sống bớt bế tắc liền, cách xử lý nó lại đơn giản tới mức mà không thể hình dung được (Phần 1: Event block). Từ hôm ấy mình có ấp ủ dư định về một cái repo đủ best practice của Nginx config để nhiều anh em tránh gặp tình trạng này tối đa. Mời mọi người cùng tham khảo, tham gia đóng góp repo này: https://github.com/mrphuongbn/nginx-best-practice-configuration
Sau đây mình xin chia sẻ kinh nghiệm của mình:
Phần 1: Event Block
worker_connections 4096;
- Thông thường, mọi người không chỉ định giá trị worker_connections trong cấu hình, do đó, nó sẽ sử dụng giá trị mặc định là 512. Điều này có nghĩa là mỗi process (vCPU) của Nginx instance có thể xử lý tối đa 512 kết nối đồng thời trừ khi được chỉ định khác trong tệp cấu hình được bao gồm. Tuỳ lượng truy cập và chất lượng CPU mà cân nhắc một con số phù hợp, mình từng để con số này tới hàng chục nghìn để làm reverse proxy cho nhiều websites mà vẫn tải tốt. Hi vọng có ai đó chia sẻ thêm về maximum hoặc cách tính của nó.
use epoll;
- Chỉ thị này thiết lập phương pháp mà Nginx sẽ sử dụng để xử lý các sự kiện trên các kết nối mạng. epoll là một phương pháp hiệu suất cao được sử dụng trên Linux 2.6 và các phiên bản sau. Nó hiệu quả hơn các phương pháp cũ như select và poll, đặc biệt khi xử lý số lượng lớn kết nối.
multi_accept on;
- Khi chỉ thị này được đặt thành on, mỗi quy trình worker sẽ chấp nhận tất cả các kết nối mới cùng một lúc, thay vì chấp nhận từng kết nối một. Điều này có thể giúp giảm độ trễ khi có nhiều kết nối đến.
Phần 2: Nén file - Compression
Bật nén Gzip.
gzip on;
gzip_static on;
Bật nén cho cả HTTP/1.0 và HTTP/1.1.
gzip_http_version 1.1;
Mức độ nén (1-9). 5 là một sự cân bằng hoàn hảo giữa size và mức sử dụng CPU, cung cấp khoảng 75% giảm kích thước cho hầu hết các tệp ASCII (gần như giống hệt mức độ 9).
gzip_comp_level 5;
Không nén bất cứ thứ gì đã nhỏ và không có khả năng giảm kích thước nhiều nếu có. (mặc định là 20 byte, điều này không hợp lý vì thường dẫn đến tệp lớn hơn sau khi nén)
gzip_min_length 256;
Nén dữ liệu ngay cả đối với các client kết nối với chúng ta qua proxy, được xác định bởi header "Via" (cần thiết cho CloudFront).
gzip_proxied any;
**Yêu cầu proxy lưu trữ cả phiên bản đã nén và không nén của tài nguyên bất cứ khi nào tiêu đề khả năng Accept-Encoding của client thay đổi; **
- Tránh vấn đề khi một client không có khả năng gzip (rất hiếm ngày nay) sẽ hiển thị ký tự lộn xộn nếu proxy của họ đưa cho họ phiên bản đã nén.
gzip_vary on;
Nén tất cả các đầu ra được gắn nhãn với một trong các MIME-types sau.
# text/html luôn được nén bởi HttpGzipModule
gzip_types
application/atom+xml
application/javascript
application/json
application/rss+xml
application/vnd.ms-fontobject
application/x-font-ttf
application/x-web-app-manifest+json
application/xhtml+xml
application/xml
font/opentype
image/svg+xml
image/x-icon
text/css
text/plain
text/x-component;
To be continued... in the GitHub repository.
All rights reserved