Cách tối ưu hóa cấu hình Nginx

Tác giả NetworkEngineer, T.Mười 28, 2021, 09:05:16 SÁNG

« Chủ đề trước - Chủ đề tiếp »

0 Thành viên và 1 Khách đang xem chủ đề.

Cách tối ưu hóa cấu hình Nginx


Nginx là một giải pháp thay thế nhanh và nhẹ cho Apache 2. Tuy nhiên, Nginx cũng giống như bất kỳ loại máy chủ hoặc phần mềm nào phải được điều chỉnh để giúp đạt được hiệu suất tối ưu.

  • Một máy chủ Debian 7 mới với quá trình thiết lập cơ bản ban đầu đã hoàn tất.
  • Máy chủ này cũng phải có một dịch vụ Nginx mới được cài đặt và cấu hình đang chạy. Hãy thử hướng dẫn Debian LEMP Stack hoặc đối với một cái gì đó cơ bản hơn một chút.
  • Hiểu biết cơ bản về Linux.

1. Worker Processes và Worker Connections.

Hai tùy chọn đầu tiên chúng ta cần điều chỉnh là Worker ProcessesWorker Connections. Trước khi chuyển sang từng cài đặt, chúng ta cần hiểu những gì mỗi lệnh này kiểm soát. Tùy chọn worker_processes là cột sống mạnh mẽ của cuộc sống cho Nginx. Tùy chọn này chịu trách nhiệm cho máy chủ ảo của chúng tôi biết có bao nhiêu worker sẽ xuất hiện sau khi nó bị ràng buộc với (các) IP và (các) cổng thích hợp. Thực tế phổ biến là chạy 1 Worker Processes cho mỗi lõi. Bất cứ điều gì ở trên này sẽ không làm tổn hại đến hệ thống của bạn, nhưng nó sẽ để lại các tiến trình nhàn rỗi thường chỉ nằm một chỗ.

Để tìm ra con số bạn sẽ cần đặt worker_processes, chỉ cần xem xét số lượng lõi bạn có trong cấu hình máy chủ của mình.

Mã nguồn [Chọn]
$ grep processor /proc/cpuinfo | wc -l
Giả sử điều này trả về giá trị là 1. Đó là số lượng lõi trên máy của chúng ta.

Các worker_connections cho worker processes biết có bao nhiêu người cùng một lúc có thể được phục vụ bởi Nginx. Giá trị mặc định là 768; tuy nhiên, xem xét rằng mọi trình duyệt thường mở ít nhất 2 kết nối/máy chủ, con số này có thể bằng một nửa. Đây là lý do tại sao chúng ta cần điều chỉnh các worker processes để phát huy hết tiềm năng của nó. Chúng ta có thể kiểm tra các giới hạn của lõi của chúng tôi bằng cách đưa ra lệnh ulimit:

Mã nguồn [Chọn]
$ ulimit -n
Trên một máy nhỏ hơn (với 512MB RAM), con số này có thể sẽ là 1024, đây là một con số khởi đầu tốt.

Hãy cập nhật cấu hình của chúng ta:

Mã nguồn [Chọn]
$ sudo nano /etc/nginx/nginx.conf
Mã nguồn [Chọn]
worker_processes 1;
worker_connections 1024;

Hãy nhớ rằng, số lượng khách truy cập có thể được phục vụ có thể được nhân với số lượng lõi. Trong trường hợp này, chúng tôi có thể phục vụ 1024 máy khách/giây. Tuy nhiên, điều này thậm chí còn được giảm thiểu hơn nữa bởi tùy chọn keepalive_timeout.

2. Bộ Buffer Cache.

Một tinh chỉnh cực kỳ quan trọng khác mà chúng ta có thể thực hiện là kích thước bộ Buffer Cache. Nếu kích thước bộ Cache quá thấp, thì Nginx sẽ phải ghi vào một tập tin tạm thời khiến đĩa đọc và ghi liên tục. Có một số tùy chọn mà chúng ta cần hiểu trước khi đưa ra bất kỳ quyết định nào.

client_body_buffer_size: Tùy chọn này xử lý kích thước bộ Cache của máy khách, có nghĩa là bất kỳ hành động POST nào được gửi đến Nginx. Các hành động POST thường là gửi biểu mẫu.

client_header_buffer_size: Tương tự như tùy chọn trước, chỉ thay vào đó nó xử lý kích thước tiêu đề máy khách. Đối với tất cả các ý định và mục đích, 1K thường là một kích thước phù hợp cho tùy chọn này.

client_max_body_size: Kích thước tối đa được phép cho một yêu cầu của khách truy cập. Nếu kích thước tối đa bị vượt quá, thì Nginx sẽ xuất hiện lỗi 413 hoặc Request Entity Too Large.

large_client_header_buffers: Số lượng và kích thước bộ Buffer Cache tối đa cho các tiêu đề khách truy cập.

Mã nguồn [Chọn]
client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 8m;
large_client_header_buffers 2 1k;

3. Timeouts.

Thời gian chờ cũng có thể cải thiện đáng kể hiệu suất.

Các tùy chọn client_body_timeoutclient_header_timeout chịu trách nhiệm về thời gian máy chủ sẽ đợi client body hoặc client header được gửi sau khi có yêu cầu. Nếu cả nội dung hoặc tiêu đề đều không được gửi, máy chủ sẽ đưa ra lỗi 408 hoặc Request time out.

Tùy chọn keepalive_timeout chỉ định thời gian chờ để duy trì kết nối với khách truy cập. Nói một cách đơn giản, Nginx sẽ đóng các kết nối với máy khách sau khoảng thời gian này.

Cuối cùng, tùy chọn send_timeout được thiết lập không dựa trên toàn bộ việc chuyển câu trả lời, mà chỉ giữa hai thao tác đọc. Nếu sau thời gian này, khách truy cập không nhận được gì, thì Nginx sẽ tắt kết nối.

Mã nguồn [Chọn]
client_body_timeout 12;
client_header_timeout 12;
keepalive_timeout 15;
send_timeout 10;

4. Nén Gzip.

Gzip có thể giúp giảm số lượng giao dịch chuyển mạng mà Nginx thực hiện. Tuy nhiên, hãy cẩn thận tăng quá cao gzip_comp_level vì nó sẽ máy chủ sẽ bắt đầu lãng phí chu kỳ CPU.

Mã nguồn [Chọn]
gzip            on;
gzip_comp_level  2;
gzip_min_length  1000;
gzip_proxied    expired no-cache no-store private auth;
gzip_types      text/plain application/x-javascript text/xml text/css application/xml;


5. Bộ Cache tập tin tĩnh.

Có thể đặt tiêu đề hết hạn cho các tập tin không thay đổi và được cung cấp thường xuyên. Tùy chọn này có thể được thêm vào khối máy chủ Nginx thực tế.

Mã nguồn [Chọn]
location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
}

Thêm và xóa bất kỳ loại tập tin nào trong mảng ở trên để khớp với loại tập tin trên máy chủ Nginx của bạn.

6. Ghi nhật ký log.

Nginx ghi lại mọi yêu cầu truy cập vào VPS vào một tập tin nhật ký. Nếu bạn sử dụng phân tích để theo dõi điều này, bạn có thể muốn tắt chức năng này. Chỉ cần chỉnh sửa tùy chọn access_log:

Mã nguồn [Chọn]
access_log off;
Lưu và đóng tập tin, sau đó chạy lệnh sau:

Mã nguồn [Chọn]
$ sudo service nginx restart
Một máy chủ được cấu hình đúng là một máy chủ được theo dõi và điều chỉnh cho phù hợp. Không có tùy chọn nào ở trên được thiết lập sẵn và sẽ cần được điều chỉnh cho từng trường hợp riêng biệt. Thậm chí xa hơn, bạn có thể đang tìm cách nâng cao hiệu suất máy chủ của mình với nghiên cứu về cân bằng tải và chia tỷ lệ ngang hàng. Đây chỉ là một vài trong số rất nhiều cải tiến mà một quản trị hệ thống tốt có thể thực hiện cho một máy chủ.