Ροή επεξεργασίας HTTP του Nginx: Ρύθμιση παραμέτρων

Η προεπιλεγμένη διαμόρφωση του Nginx έχει σχεδιαστεί με γνώμονα τη συμβατότητα και όχι την απόδοση. Με τη σωστή ρύθμιση, ένας μεμονωμένος διακομιστής μπορεί να διαχειριστεί 50.000 έως 80.000 αιτήσεις ανά δευτερόλεπτο. Αυτός ο οδηγός καλύπτει τις ρυθμίσεις που έχουν τη μεγαλύτερη σημασία: διεργασίες εργαζομένων, συνδέσεις, keepalive, buffering, εξισορρόπηση φορτίου και πώς να επαληθεύσετε τις αλλαγές σας με δοκιμές επιδόσεων.

Πώς επεξεργάζεται το Nginx τα αιτήματα HTTP

Το Nginx χειρίζεται τα αιτήματα σε ξεχωριστές φάσεις, καθεμία από τις οποίες καταναλώνει πόρους του συστήματος. Η κατανόηση της ροής σας βοηθά να στοχεύσετε τις σωστές ρυθμίσεις.

Ξεκινά σε επίπεδο πυρήνα. Οι εισερχόμενες συνδέσεις καταλήγουν στις ουρές SYN και ACCEPT, και οι διεργασίες εργασίας του Nginx τις παραλαμβάνουν. Μόλις γίνει αποδεκτή, η διεργασία εργασίας αναλύει το αίτημα HTTP από το buffer του πυρήνα. Η κίνηση TLS καθιστά αυτό το βήμα πιο απαιτητικό για την CPU.

Στη συνέχεια, το Nginx αντιστοιχίζει το αίτημα σε έναν εικονικό διακομιστή χρησιμοποιώντας την κεφαλίδα Host και τον συνδυασμό IP/θύρας, και στη συνέχεια επιλύει το URI σε ένα μπλοκ τοποθεσίας μέσω αντιστοίχισης προθέματος ή κανονικής έκφρασης.

Για δυναμικό περιεχόμενο, το Nginx προωθεί το αίτημα σε ένα backend (FastCGI, proxy). Αυτή η φάση επικοινωνίας upstream επωφελείται σε μεγάλο βαθμό από τις μόνιμες συνδέσεις. Χωρίς upstream keepalive, το Nginx ανοίγει μια νέα σύνδεση TCP ανά αίτημα, προσθέτοντας καθυστέρηση και επιβάρυνση της CPU.

Εάν proxy_buffering είναι ενεργοποιημένο, το Nginx διαβάζει ολόκληρη την ανταπόκριση upstream στη μνήμη πριν την παραδώσει στον πελάτη. Αυτό απελευθερώνει τον εργαζόμενο ώστε να χειριστεί αμέσως νέα αιτήματα. Τέλος, κατά τη διάρκεια της παράδοσης εξόδου, η ενεργοποίηση του sendfile επιτρέπει μεταφορές χωρίς αντιγραφή, οι οποίες μπορούν να αυξήσουν τη διακίνηση από περίπου 6 Gbps σε 30 Gbps.

Κάθε φάση καταναλώνει buffer μνήμης, περιγραφείς αρχείων και κύκλους CPU. Οι παρακάτω ενότητες στοχεύουν σε κάθε σημείο συμφόρησης.

Διαδικασίες και συνδέσεις εργαζομένων

Ξεκινήστε με worker_processes auto; στο κύριο πλαίσιο σας. Αυτό αντιστοιχεί τον αριθμό των εργαζομένων στους πυρήνες της CPU σας. Σε ένα VPS με περιορισμένους πυρήνες, ορίστε τον αριθμό χειροκίνητα (π.χ. worker_processes 2;). Εάν το φορτίο εργασίας σας απαιτεί μεγάλη χρήση μνήμης, εξετάστε το ενδεχόμενο να μειώσετε τον αριθμό των εργαζομένων για να αποφύγετε την υπερβολική χρήση της μνήμης RAM.

Ενεργοποιήστε worker_cpu_affinity auto; για να αντιστοιχίσετε κάθε εργαζόμενο σε έναν συγκεκριμένο πυρήνα. Αυτό μειώνει τις αποτυχίες της κρυφής μνήμης και την εναλλαγή περιβάλλοντος. Διαθέσιμο από την έκδοση Nginx 1.9.10.

Όρια σύνδεσης

Η worker_connections ορίζει πόσες ταυτόχρονες συνδέσεις μπορεί να χειριστεί κάθε worker. Η συνολική χωρητικότητα είναι worker_processes × worker_connections. Η προεπιλογή των 512 ή 1.024 είναι πολύ χαμηλή για περιβάλλον παραγωγής. Ρυθμίστε την σε 2.048 ή 4.096 ανά worker για ιστότοπους με υψηλή επισκεψιμότητα.

Κάθε σύνδεση χρειάζεται τουλάχιστον έναν περιγραφέα αρχείου. Σε μια ρύθμιση αντίστροφου διακομιστή μεσολάβησης, κάθε σύνδεση χρησιμοποιεί δύο (έναν για τον πελάτη, έναν για τον ανάντη διακομιστή). Ορίστε worker_rlimit_nofile την τιμή τουλάχιστον στο διπλάσιο της worker_connections τιμή σας με περιθώριο. Για worker_connections 4096;, χρησιμοποιήστε worker_rlimit_nofile 10000; ή υψηλότερη τιμή.

Σε επίπεδο συστήματος, αυξήστε fs.file-max το /etc/sysctl.conf σε τουλάχιστον 500.000 και ρυθμίστε το LimitNOFILE=65535.

Τέλος, προσθέστε multi_accept on; στο μπλοκ events ώστε οι workers να δέχονται όλες τις εκκρεμείς συνδέσεις ταυτόχρονα αντί για μία κάθε φορά.

Timeouts και Keepalive

Keepalive πελάτη

Η keepalive_timeout οδηγία ελέγχει πόσο καιρό παραμένουν ανοιχτές οι αδρανείς συνδέσεις πελατών. Για διακομιστές με υψηλή κίνηση, τα 30 έως 65 δευτερόλεπτα λειτουργούν καλά. Χρησιμοποιήστε τη μορφή δύο παραμέτρων:

keepalive_timeout 65s 60s;

Η πρώτη τιμή είναι το χρονικό όριο από την πλευρά του διακομιστή. Η δεύτερη στέλνει μια Keep-Alive: timeout=60 κεφαλίδα στον πελάτη. Ρυθμίζοντας την τιμή του πελάτη ελαφρώς χαμηλότερα αποτρέπονται οι συνθήκες ανταγωνισμού όπου τα προγράμματα περιήγησης προσπαθούν να επαναχρησιμοποιήσουν συνδέσεις που το Nginx έχει ήδη κλείσει.

Η keepalive_requests οδηγία περιορίζει τον αριθμό των αιτήσεων που μπορεί να χειριστεί μια μεμονωμένη σύνδεση πριν τερματιστεί. Η προεπιλογή είναι 1.000 (αυξήθηκε από 100 στην έκδοση 1.19.10). Για σταθερά backends, αυξήστε την τιμή αυτή σε 10.000 για να μειώσετε την ανανέωση των συνδέσεων.

Τα χρονικά όρια διακομιστή μεσολάβησης

proxy_connect_timeout ορίζει πόσο καιρό περιμένει το Nginx για να δημιουργήσει μια σύνδεση με το backend. Η προεπιλογή είναι 60 δευτερόλεπτα. Μειώστε την σε 5 έως 10 δευτερόλεπτα για γρήγορη ανακατεύθυνση.

proxy_read_timeout ορίζει πόσο χρόνο περιμένει το Nginx μεταξύ διαδοχικών αναγνώσεων από το upstream. Προσαρμόστε το στο χρονικό όριο εκτέλεσης του backend σας. Εάν το request_terminate_timeout είναι 120 δευτερόλεπτα, ρυθμίστε proxy_read_timeout σε τουλάχιστον 120 δευτερόλεπτα για να αποφύγετε πρόωρα σφάλματα 504.

proxy_send_timeout ελέγχει το διάστημα μεταξύ διαδοχικών εγγραφών στο upstream. Η προεπιλογή των 60 δευτερολέπτων είναι συνήθως ικανοποιητική, εκτός αν στέλνετε μεγάλα σώματα αιτήσεων.

Κατά κανόνα, proxy_connect_timeout θα πρέπει πάντα να είναι το μικρότερο από τα τρία.

Μέγεθος buffer

client_body_buffer_size ελέγχει πόσο από το σώμα μιας εισερχόμενης αίτησης διατηρεί το Nginx στη μνήμη. Η προεπιλογή των 8k ή 16k χειρίζεται απλές υποβολές φορμών, αλλά οι μεταφορτώσεις αρχείων θα μεταφερθούν στο δίσκο. Αυξήστε το σε 128k για μικρές έως μεσαίες μεταφορτώσεις. Αυξήστε client_max_body_size από την προεπιλεγμένη τιμή του 1m εάν οι χρήστες ανεβάζουν μεγαλύτερα αρχεία.

proxy_buffer_size χειρίζεται τις κεφαλίδες απόκρισης ξεχωριστά από το σώμα. Η προεπιλογή των 4k ή 8k συνήθως λειτουργεί, αλλά οι εφαρμογές με μεγάλες Set-Cookie κεφαλίδες (συνηθισμένο στο ηλεκτρονικό εμπόριο) μπορεί να το υπερβούν, προκαλώντας σφάλματα 502. Μετρήστε το πραγματικό μέγεθος της κεφαλίδας σας:

curl -s -w '%{size_header}' -o /dev/null http://your-upstream-url

Στρογγυλοποιήστε προς τα πάνω στο πλησιέστερο βήμα των 4k.

proxy_buffers ορίζει τον αριθμό και το μέγεθος των buffer για το σώμα της απόκρισης. Η προεπιλογή (8 buffer των 4k ή 8k, συνολικά 32k έως 64k) δεν θα χωρέσει μια μεγάλη απόκριση JSON. Μετρήστε τη μεγαλύτερη τυπική απόκρισή σας με curl και ρυθμίστε αρκετούς buffer ώστε να τη διατηρείτε εξ ολοκλήρου στη μνήμη RAM.

Συμπεριφορά buffer του proxy

Με proxy_buffering on (η προεπιλογή), το Nginx διαβάζει ολόκληρη την ανταπόκριση από τον upstream στη μνήμη πριν την στείλει στον πελάτη. Αυτό επιτρέπει στους διακομιστές backend να προχωρήσουν αμέσως σε νέες αιτήσεις.

Ορίστε proxy_busy_buffers_size σε τουλάχιστον proxy_buffer_size συν ένα buffer, αλλά λιγότερο από το συνολικό buffer pool σας. Για proxy_buffers 8 16k (συνολικά 128k), διατηρήστε proxy_busy_buffers_size κάτω από 112k.

Για τερματικά σε πραγματικό χρόνο όπως τα Server-Sent Events ή το long-polling, απενεργοποιήστε την προσωρινή αποθήκευση με proxy_buffering off σε ένα μπλοκ συγκεκριμένης τοποθεσίας. Εφαρμόστε αυτό επιλεκτικά σε /stream ή /events διαδρομές, όχι σε παγκόσμιο επίπεδο.

Εξισορρόπηση φορτίου και Upstream Keepalive

Από προεπιλογή, το Nginx ανοίγει μια νέα σύνδεση TCP για κάθε αίτημα που διαμεσολαβείται. Κάθε χειραψία προσθέτει 10 έως 100 ms καθυστέρησης, με το TLS να προσθέτει άλλα 10 έως 50 ms. Το Upstream keepalive διατηρεί μια ομάδα μόνιμων συνδέσεων για την εξάλειψη αυτού του επιπλέον φόρτου.

Απαιτούνται τρεις ρυθμίσεις:

upstream backend {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    keepalive 128;
}
 
server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

Η keepalive τιμή καθορίζει τον μέγιστο αριθμό αδρανών συνδέσεων ανά worker. Υπολογίστε το βέλτιστο μέγεθος της ομάδας ως εξής: (workers × target concurrency) / upstream nodes.

Ορίστε το upstream keepalive_timeout σε 60 έως 120 δευτερόλεπτα για να ταιριάζει με τις ρυθμίσεις του backend σας και να χειρίζεται τις αιχμές της κυκλοφορίας.

Στρατηγικές εξισορρόπησης

Το Nginx υποστηρίζει διάφορες μεθόδους εξισορρόπησης φορτίου. Η μέθοδος Round-robin (η προεπιλεγμένη) κατανέμει τα αιτήματα διαδοχικά. least_conn Το round-robin δρομολογεί προς τον διακομιστή με τις λιγότερες ενεργές συνδέσεις, κάτι που ταιριάζει σε φόρτους εργασίας με μεταβλητή διάρκεια αιτήσεων. ip_hash Παρέχει διατήρηση συνεδρίας δρομολογώντας την ίδια IP πελάτη στο ίδιο backend.

Χρησιμοποιήστε την weight παράμετρο όταν οι διακομιστές έχουν διαφορετικές χωρητικότητες:

upstream backend {
    least_conn;
    server 10.0.1.10:8080 weight=3;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080 backup;
    keepalive 128;
}

Ο σταθμισμένος διακομιστής λαμβάνει τριπλάσια κίνηση. Ο backup διακομιστής ενεργοποιείται μόνο εάν όλοι οι κύριοι διακομιστές είναι εκτός λειτουργίας. Διαμορφώστε max_fails και fail_timeout για παθητικούς ελέγχους καλής λειτουργίας και χρησιμοποιήστε max_conns για να περιορίσετε τις ταυτόχρονες συνδέσεις ανά backend.

Δοκιμές και παρακολούθηση

Μετράτε πάντα τη βασική απόδοση πριν κάνετε οποιαδήποτε αλλαγή. Μετά από κάθε αλλαγή, πραγματοποιήστε ξανά τη μέτρηση. Κάντε μία αλλαγή κάθε φορά.

Επαληθεύστε τη σύνταξη της διαμόρφωσής σας με nginx -t πριν από την επαναφόρτωση. Εκτελέστε τις δοκιμές από ξεχωριστό υπολογιστή για να αποφύγετε την ανταγωνιστική χρήση πόρων.

Το wrk είναι το τυπικό εργαλείο για δοκιμές φόρτωσης HTTP:

wrk -t4 -c200 -d30s http://your-server.com/

Παρακολουθήστε τις αιτήσεις ανά δευτερόλεπτο, τη μέση καθυστέρηση, τη μέγιστη καθυστέρηση και τον ρυθμό μεταφοράς. Το Apache Bench λειτουργεί για απλούστερες δοκιμές:

ab -n 50000 -c 40 http://your-server.com/

Συνεχής παρακολούθηση

Ενεργοποιήστε το stub_status ενότητα για να παρακολουθείτε τις ενεργές συνδέσεις σε πραγματικό χρόνο μέσω curl http://localhost/nginx_status.

Προσθέστε μεταβλητές χρονισμού στη μορφή καταγραφής σας για να εντοπίσετε πού συμβαίνουν καθυστερήσεις:

• $request_time για τη συνολική διάρκεια του αιτήματος
• $upstream_connect_time για το χρόνο σύνδεσης με το backend
• $upstream_response_time για τον συνολικό χρόνο επεξεργασίας του backend

Ελέγξτε τα αρχεία καταγραφής σφαλμάτων για προβλήματα buffer με journalctl -u nginx --no-pager | grep "temporary file". Εάν οι απαντήσεις καταλήγουν στο δίσκο, το proxy_buffers είναι πολύ μικρά. Αναζητήστε σφάλματα "too many open files", τα οποία υποδηλώνουν worker_rlimit_nofile πρέπει να αυξηθούν.

Μειώστε τις εισόδους/εξόδους καταγραφής με καταγραφή σε buffer:

access_log /var/log/nginx/access.log combined buffer=64k flush=5s;

Χρησιμοποιήστε ss -tn state established dst [backend_ip] κατά τη διάρκεια των δοκιμών φόρτωσης για να επαληθεύσετε ότι οι συνδέσεις επαναχρησιμοποιούνται και δεν συσσωρεύονται στο TIME_WAIT.

Για αποκλειστικούς διακομιστές και φιλοξενία VPS βελτιστοποιημένα για φόρτους εργασίας υψηλής απόδοσης, ανατρέξτε στους διακομιστές FDC.