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

5 năm trước

Giới thiệu

Nginx

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

Yêu cầu

Một Debian 7 VPS mới với thiết lập ban đầu đã hoàn thành.
Các VPS cũng phải có một server Nginx đang chạy mới được cài đặt và định cấu hình.
Hiểu biết tốt về Linux basics.

Worker processes và Worker connections

Hai biến đầu tiên cần điều chỉnh là worker processes và worker connections. Trước khi đi vào từng điều chỉnh, chúng ta cần phải hiểu các chỉ thị này kiểm soát những gì. Chỉ thị worker_processes là cột sống mạnh mẽ của Nginx, chịu trách nhiệm cho phép máy chủ ảo biết nhiều workers sản sinh khi đã trở thành ràng buộc với IP và (các) cổng thích hợp. Đó là thực tế phổ biến để chạy 1 worker process trên mỗi lõi. Bất cứ điều gì ở trên sẽ không làm hại hệ thống của bạn, nhưng nó sẽ để lại các quá trình vô hiệu thường chỉ bịa đặt ra.

Để tìm ra số nào đặt worker_processes, chỉ cần xem xét số lượng lõi mà bạn có trên thiết lập của mình. Nếu bạn đang sử dụng thiết lập DigitalOcean 512MB, thì nó có thể sẽ là một lõi. Nếu bạn kết thúc thay đổi kích thước nhanh thành thiết lập lớn hơn, thì sẽ cần phải kiểm tra lại lõi của mình và điều chỉnh con số này cho phù hợp. Chúng ta có thể thực hiện điều này bằng cách tìm ra cpuinfo:

grep processor /proc/cpuinfo | wc -l

Hãy nói rằng điều này trả về một giá trị của 1. Sau đó thì chính là số lượng lõi trên máy tính của chúng ta!

Lệnh worker_connections cho biết worker processes có bao nhiêu người có thể được Nginx phục vụ đồng thời. Giá trị mặc định là 768; tuy nhiên,nếu xét mọi trình duyệt thường mở ra í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 cần phải điều chỉnh worker connections với tiềm năng đầy đủ của nó. Chúng ta có thể kiểm tra các giới hạn của lõi bằng cách đưa ra một lệnh ulimit:

ulimit -n

Trên một máy nhỏ hơn (512MB VPS) con số này có thể đọc 1024, đó là một số khởi đầu tốt.

Hãy cập nhật cấu hình:

sudo nano /etc/nginx/nginx.conf

worker_processes 1;
worker_connections 1024;

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

Bộ đệm

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

client_body_buffer_size: Điều này xử lý kích thước bộ đệm của client, có nghĩa là bất kỳ hành động POST nào được gửi tới Nginx. Hành động POST thường là biểu mẫu gửi.

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

client_max_body_size: Kích thước tối đa cho phép đối với yêu cầu của client. Nếu kích thước tối đa vượt quá, Nginx sẽ gặp lỗi 413 hoặc Request Entity Too Large.

large_client_header_buffers: Số lượng và kích thước bộ đệm tối đa cho các tiêu đề client lớn.

client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 8m;
large_client_header_buffers 2 1k;

Thời gian chờ

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

Chỉ thị client_body_timeout và client_header_timeout chịu trách nhiệm về thời gian máy chủ sẽ đợi đối với chủ thể client hoặc tiêu đề client được gửi sau khi yêu cầu. Nếu không phải là chủ thể hoặc tiêu đề được gửi, máy chủ sẽ phát hiện lỗi 408 hoặc Request time out.

keepalive_timeout gán thời gian chờ cho các kết nối lưu động với client. Nói một cách đơn giản, Nginx sẽ kết nối chặt chẽ với client sau khoảng thời gian này.

Cuối cùng, send_timeout được thiết lập không phải trên toàn bộ việc chuyển giao câu trả lời, mà chỉ giữa hai hoạt động đọc; nếu sau khi client này không có gì, Nginx sẽ tắt kết nối.

client_body_timeout 12;
client_header_timeout 12;
keepalive_timeout 15;
send_timeout 10;

Nén Gzip

Gzip giúp giảm số lượng chuyển giao Nginx trên mạng. Tuy nhiên, hãy cẩn thận khi tăng gzip_comp_level quá cao vì máy chủ sẽ bắt đầu bỏ qua các chu kỳ CPU.

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;

Lưu trữ tệp tĩnh

Có thể đặt tiêu đề hết hạn cho các tệp không thay đổi và được phân phối thường xuyên. Chỉ thị này có thể được thêm vào khối máy chủ Nginx thực tế.

location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
}

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

Ghi nhật ký

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

access_log off;

Lưu và đóng tệp, sau đó chạy:

sudo service nginx restart

Kết luận

Vào cuối ngày, máy chủ được định dạng đúng là máy chủ được theo dõi và điều chỉnh phù hợp. Không có biến nào ở trên là cố định và cần được điều chỉnh cho từng trường hợp duy nhất. Thậm chí trong tương lai, bạn có thể tìm cách để tiếp tục hiệu suất máy với nghiên cứu cân bằng tải và mở rộng theo chiều ngang. Đây chỉ là một vài trong số rất nhiều cải tiến mà một sysadmin tốt có thể thực hiện cho máy chủ.