Bài viết đề cập đến các cấu hình chính để tối ưu hiệu năng web server nginx, bao gồm nén gzip, cài đặt proxy_buffer, cấu hình worker và keep-alive.
Đặc biệt, bài viết nhấn mạnh tầm quan trọng của việc nén gzip và sử dụng bộ đệm proxy_buffer để giảm lượng dữ liệu truyền và giảm tải cho server, cũng như quản lý kết nối thông qua cấu hình worker process và keep-alive.
Bài viết đề xuất các bước kiểm thử đa dạng để áp dụng cấu hình tối ưu phù hợp với môi trường server và lưu ý để vận hành server ổn định.
Nginx là một phần mềm mã nguồn mở, thường được sử dụng làm máy chủ web hoặc máy chủ proxy web.
Với cấu hình phù hợp, nó có thể cung cấp nội dung tĩnh hiệu quả.
Tôi muốn ghi lại một số cấu hình chính trong số đó.
Một số cấu hình chính liên quan đến hiệu suất
1. Nén gzip
Khi tải một trang web, bạn nhận được rất nhiều tệp từ máy chủ web, chẳng hạn như JavaScript, hình ảnh, HTML và CSS.
Thay vì gửi những nội dung này ở dạng gốc, việc sử dụng nén gzip có thể làm giảm đáng kể lượng dữ liệu được truyền.
Cụ thể, khi áp dụng điều này:
- Giảm lượng dữ liệu, tiết kiệm băng thông.
- Tiết kiệm tài nguyên máy chủ.
- Đối với người dùng, tốc độ tải thực tế sẽ nhanh hơn.
Mặt khác, vì máy chủ phải thực hiện nén gzip trước khi trả lời nội dung, nên việc sử dụng CPU của máy chủ có thể tăng lên.
Việc nén loại tệp nào, mức độ nén là bao nhiêu và kích thước tệp nào nên được nén cần được kiểm tra kỹ lưỡng trước khi áp dụng vào môi trường sản xuất.
Dưới đây là một số cài đặt liên quan đến gzip.
gzip on; # Thiết lập nén gzip.
gzip_vary on; # Thêm Vary: Accept-Encoding vào tiêu đề.
gzip_proxied any; # Nếu nginx được sử dụng làm máy chủ proxy, hãy nén phản hồi nhận được từ backend. (Nén cho các yêu cầu được proxy)
gzip_min_length 256; # Chỉ nén các tệp có kích thước từ 256 trở lên
gzip_comp_level 5; # Thiết lập mức nén từ 1 đến 9. Càng cao thì sử dụng CPU càng nhiều. 5 nén khoảng 50%.
gzip_types text/plain text/css text/xml application/json application/javascript;
// Thiết lập kiểu nội dung cần nén.
* gzip_vary chỉ định rằng nội dung có thể được gửi ở cả phiên bản đã nén và chưa nén tùy thuộc vào việc máy khách có hỗ trợ gzip hay không. (Cho biết nội dung có thể được cung cấp ở các phiên bản khác nhau tùy thuộc vào tiêu đề yêu cầu (Accept-Encoding) của máy khách.)
2. Cấu hình proxy_buffer
Nginx lưu trữ phản hồi vào bộ đệm trước khi gửi phản hồi cho máy khách.
Khi máy chủ web gửi phản hồi cho máy khách, nếu tốc độ của máy khách chậm, máy chủ phải chờ để truyền dữ liệu. (Hiện tượng nghẽn cổ chai mạng)
Điều này dẫn đến việc sử dụng liên tục tài nguyên máy chủ, vì vậy để giải quyết vấn đề này, bộ đệm được sử dụng để xử lý tạm thời phản hồi bất kể tốc độ xử lý máy khách. Điều này mang lại những lợi ích sau:
- Tối ưu hóa tải máy chủ
- Giảm nghẽn cổ chai mạng
location / {
proxy_pass url_server;
# Cấu hình bộ đệm proxy
proxy_buffering on; # Bật bộ đệm.proxy_buffer_size 4k; # Thiết lập kích thước của bộ đệm.(Chủ yếu chứa tiêu đề.) proxy_buffers 8 4k; # Số lượng và kích thước của bộ đệm cho mỗi kết nối(8 bộ đệm 4kb) proxy_busy_buffers_size 8k; # Kích thước bộ đệm tối đa có thể sử dụng khi gửi phản hồi cho máy khách
}
※ Nếu kích thước bộ đệm quá lớn, việc truyền dữ liệu thời gian thực như luồng văn bản có thể bị chậm lại, vì vậy cần phải kiểm tra. Đặc biệt là gần đây có rất nhiều dịch vụ liên quan đến AI, vì vậy nếu luồng văn bản không hoạt động, hãy kiểm tra cài đặt này.
3. Cấu hình worker và http
Worker là một tiến trình xử lý các yêu cầu của máy khách và bạn có thể thiết lập số lượng worker cho mỗi lõi CPU của máy chủ.
HTTP thường là yêu cầu - kết nối - phản hồi - đóng kết nối, nhưng để giảm tài nguyên kết nối cho nhiều yêu cầu, bạn có thể duy trì kết nối máy khách. Đó là cài đặt keep alive.
worker_processes auto; # Tự động đặt theo số lõi CPU khả dụng
worker_connections 1024; # Số lượng kết nối mà mỗi worker có thể xử lý đồng thời
# Cài đặt keep-alive
keepalive_timeout 65;
keepalive_requests 100;
server {
listen 80;
location / {
proxy_pass url_server;
}
}
Lý do nhóm hai cái này lại với nhau như sau:
Nếu máy chủ của bạn có 4 lõi, về mặt lý thuyết, số lượng kết nối khả dụng là 1.024 * 4 = 4.096.
(Có thể không chính xác tùy thuộc vào tài nguyên hoặc môi trường lưu lượng)
Khi 4.096 máy khách kết nối đồng thời và chiếm giữ tất cả keepalive trong 65 giây,
người dùng thứ 4.097 cố gắng kết nối sẽ không thể kết nối, dẫn đến sự chậm trễ trong phản hồi.
Do đó, giả sử tài nguyên máy chủ ổn định nhờ tự động mở rộng quy mô, nếu có sự chậm trễ trong phản hồi trong trường hợp có sự kiện, thì cài đặt trên có thể ảnh hưởng gián tiếp.
4. Khác - khối location
Một số cài đặt như bộ đệm proxy có thể được áp dụng cho từng URL yêu cầu.
* Một số cài đặt như keep-alive được áp dụng ở cấp độ HTTP/Server và không thể được đặt cho từng khối.
server { listen 80; server_name example.com;
# Xử lý đường dẫn cơ sở(/)location/{ proxy_pass url_server; # Cài đặt bộ đệm
proxy_buffering on; proxy_buffers 8 16k; proxy_buffer_size 32k; proxy_busy_buffers_size 64k;}# Xử lý đường dẫn /test
location/test { proxy_pass url_server2; # Tắt bộ đệm
proxy_buffering off; # Tắt bộ đệm(gửi phản hồi ngay lập tức)}}
Thông qua các cài đặt trên, bạn có thể tối ưu hóa hiệu suất web. Hãy xem xét nhiều trường hợp thử nghiệm và kiểm tra kỹ lưỡng trước khi tối ưu hóa hiệu suất máy chủ!
* Bạn có thể áp dụng nginx với cấu hình đã được thay đổi mà không cần thời gian chết của máy chủ, vì vậy nó khá ổn định.