Nginx HTTP İşleme Akışı: Yapılandırma Ayarlaması

Nginx'in varsayılan yapılandırması, performans için değil uyumluluk için tasarlanmıştır. Uygun ayarlamalarla, tek bir sunucu saniyede 50.000 ila 80.000 istek işleyebilir. Bu kılavuz, en önemli ayarları ele almaktadır: işçi süreçleri, bağlantılar, keepalive, arabellekleme, yük dengeleme ve değişikliklerinizi karşılaştırmalı testlerle nasıl doğrulayacağınız.

Nginx HTTP İsteklerini Nasıl İşler?

Nginx, istekleri her biri sistem kaynaklarını tüketen farklı aşamalarda işler. Akışı anlamak, doğru ayarları belirlemenize yardımcı olur.

Bu süreç çekirdek düzeyinde başlar. Gelen bağlantılar SYN ve ACCEPT kuyruklarına girer ve Nginx işçi süreçleri bunları alır. Kabul edildikten sonra, işçi çekirdek tamponundan HTTP isteğini ayrıştırır. TLS trafiği bu adımı CPU açısından daha yoğun hale getirir.

Ardından, Nginx, Host başlığını ve IP/bağlantı noktası kombinasyonunu kullanarak isteği bir sanal sunucuyla eşleştirir, ardından önek veya düzenli ifade eşleşmesi yoluyla URI'yi bir konum bloğuna çözümler.

Dinamik içerik için Nginx, isteği bir arka uca (FastCGI, proxy) iletir. Bu yukarı akış iletişim aşaması, kalıcı bağlantılardan büyük ölçüde yararlanır. Yukarı akış keepalive olmadan Nginx, istek başına yeni bir TCP bağlantısı açar ve bu da gecikme ve CPU yükünü artırır.

etkinse proxy_buffering etkinleştirilirse, Nginx, istemciye teslim etmeden önce tüm yukarı akış yanıtını belleğe okur. Bu, işçinin yeni istekleri hemen işleyebilmesini sağlar. Son olarak, çıktı teslimi sırasında sendfile seçeneğini etkinleştirmek, sıfır kopyalı aktarımlara olanak tanır ve bu da verimi yaklaşık 6 Gbps'den 30 Gbps'ye çıkarabilir.

Her aşama bellek tamponlarını, dosya tanımlayıcılarını ve CPU döngülerini tüketir. Aşağıdaki bölümler her bir darboğazı ele almaktadır.

İşçi Süreçleri ve Bağlantılar

Ana bağlamınızda worker_processes auto; ile başlayın. Bu, işçi sayısını CPU çekirdeklerinizle eşleştirir. Sınırlı çekirdeğe sahip bir VPS'de, sayıyı manuel olarak ayarlayın (ör. worker_processes 2;). İş yükünüz bellek yoğunsa, RAM'i aşırı yüklemekten kaçınmak için işçi sayısını azaltmayı düşünün.

Etkinleştir worker_cpu_affinity auto; seçeneğini etkinleştirin. Bu, önbellek kaçırma ve bağlam değiştirme durumlarını azaltır. Nginx 1.9.10 sürümünden itibaren kullanılabilir.

Bağlantı sınırları

worker_connections yönergesi, her işçinin aynı anda kaç bağlantıyı işleyebileceğini belirler. Toplam kapasite worker_processes × worker_connections. Varsayılan değer olan 512 veya 1.024, üretim ortamı için çok düşüktür. Yüksek trafikli siteler için işçi başına 2.048 veya 4.096 olarak ayarlayın.

Her bağlantının en az bir dosya tanımlayıcısına ihtiyacı vardır. Ters proxy kurulumunda, her bağlantı iki tane kullanır (biri istemci, biri de yukarı akış için). worker_rlimit_nofile değerini, mevcut değerinizin en az iki katı olacak şekilde worker_connections değerin en az iki katı olacak şekilde ayarlayın. worker_connections 4096;, worker_rlimit_nofile 10000; veya daha yüksek bir değer kullanın.

Sistem düzeyinde fs.file-max değerini /etc/sysctl.conf değerini en az 500.000'e yükseltin ve systemd'nin LimitNOFILE=65535.

Son olarak, multi_accept on; olaylar bloğuna ekleyin, böylece işçiler bekleyen tüm bağlantıları tek tek değil, bir kerede kabul etsinler.

Zaman Aşımları ve Keepalive

İstemci keepalive

keepalive_timeout yönergesi, atıl durumdaki istemci bağlantılarının ne kadar süre açık kalacağını kontrol eder. Yoğun trafiğe sahip sunucular için 30 ila 65 saniye uygun bir süredir. İki parametreli biçimi kullanın:

keepalive_timeout 65s 60s;

İlk değer sunucu tarafındaki zaman aşımıdır. İkincisi, Keep-Alive: timeout=60 başlığını istemciye gönderir. İstemci değerini biraz daha düşük ayarlamak, tarayıcıların Nginx'in zaten kapattığı bağlantıları yeniden kullanmaya çalıştığı yarış durumlarını önler.

Bu keepalive_requests yönergesi, tek bir bağlantının sonlandırılmadan önce işleyebileceği istek sayısını sınırlar. Varsayılan değer 1.000'dir (1.19.10 sürümünde 100'den yükseltilmiştir). Kararlı arka uçlar için, bağlantı kayıplarını azaltmak amacıyla bu değeri 10.000'e yükseltin.

Proxy zaman aşımları

proxy_connect_timeout , Nginx'in arka uçla bağlantı kurmak için ne kadar bekleyeceğini belirler. Varsayılan değer 60 saniyedir. Hızlı yük devretme için bunu 5 ila 10 saniyeye düşürün.

proxy_read_timeout Nginx'in upstream'den ardışık okumalar arasında ne kadar bekleyeceğini tanımlar. Bunu arka ucunuzun yürütme zaman aşımıyla uyumlu hale getirin. PHP-FPM'nin request_terminate_timeout 120 saniye ise, proxy_read_timeout değerini en az 120 saniyeye ayarlayın.

proxy_send_timeout , upstream'e yapılan ardışık yazma işlemleri arasındaki aralığı kontrol eder. Büyük istek gövdeleri göndermiyorsanız, varsayılan 60 saniye değeri genellikle uygundur.

Kural olarak, proxy_connect_timeout her zaman üçü arasında en kısa olanı olmalıdır.

Tampon Boyutu

client_body_buffer_size , Nginx'in gelen istek gövdesinin ne kadarını bellekte tutacağını kontrol eder. Varsayılan 8k veya 16k değeri basit form gönderimlerini işler, ancak dosya yüklemeleri diske aktarılır. Küçük ve orta boy yüklemeler için bu değeri 128k'ya yükseltin. client_max_body_size Kullanıcılar daha büyük dosyalar yüklüyorsa, varsayılan 1m değerinden artırın.

proxy_buffer_size , yanıt başlıklarını gövdeden ayrı olarak işler. Varsayılan 4k veya 8k değeri genellikle işe yarar, ancak büyük Set-Cookie başlıkları olan uygulamalar (e-ticarette yaygındır) bu değeri aşabilir ve 502 hatalarına neden olabilir. Gerçek başlık boyutunuzu ölçün:

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

En yakın 4k artışına yuvarlayın.

proxy_buffers yanıt gövdesi için tamponların sayısını ve boyutunu ayarlar. Varsayılan ayar (4k veya 8k'lık 8 tampon, toplamda 32k ila 64k) büyük bir JSON yanıtını barındıramaz. curl ve yanıtın tamamını RAM'de tutacak kadar tampon yapılandırın.

Proxy arabellekleme davranışı

(varsayılan) proxy_buffering on (varsayılan), Nginx, istemciye göndermeden önce tam yukarı akış yanıtını belleğe okur. Bu, arka uç sunucularının hemen yeni isteklere geçmesini sağlar.

'yi proxy_busy_buffers_size değerini en az proxy_buffer_size artı bir tampon olarak ayarlayın, ancak toplam tampon havuzunuzdan daha az olmalıdır. proxy_buffers 8 16k (toplam 128k) proxy_busy_buffers_size 112k'nın altında tutun.

Server-Sent Events veya uzun aralıklı sorgulama gibi gerçek zamanlı uç noktalar için, proxy_buffering off konuma özgü bir blokta devre dışı bırakın. Bunu seçici olarak /stream yollara /events yollara seçici olarak uygulayın, genel olarak değil.

Yük Dengeleme ve Upstream Keepalive

Varsayılan olarak, Nginx her proxy istek için yeni bir TCP bağlantısı açar. Her el sıkışma işlemi 10 ila 100 ms gecikme ekler, TLS ise buna 10 ila 50 ms daha ekler. Upstream keepalive, bu ek yükü ortadan kaldırmak için kalıcı bağlantı havuzunu korur.

Üç ayar gereklidir:

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 değeri, işçi başına maksimum boşta kalma bağlantı sayısını belirler. Optimum havuz boyutunu şu şekilde hesaplayın: (workers × target concurrency) / upstream nodes.

Upstream keepalive_timeout değerini arka uç ayarlarınıza uyacak ve trafik artışlarını yönetecek şekilde 60 ila 120 saniyeye ayarlayın.

Dengeleme stratejileri

Nginx, çeşitli yük dengeleme yöntemlerini destekler. Round-robin (varsayılan), istekleri sırayla dağıtır. least_conn , aktif bağlantı sayısı en az olan sunucuya yönlendirir; bu, istek süreleri değişken olan iş yükleri için uygundur. ip_hash aynı istemci IP'sini aynı arka uca yönlendirerek oturum kalıcılığı sağlar.

Sunucuların kapasiteleri farklı olduğunda weight parametresini kullanın:

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;
}

Ağırlıklı sunucu, trafiğin üç katını alır. backup sunucu, yalnızca tüm birincil sunucular kapalıysa etkinleşir. max_fails ve fail_timeout pasif durum denetimleri için yapılandırın ve max_conns 'yi kullanarak arka uç başına eşzamanlı bağlantı sayısını sınırlayın.

Test ve İzleme

Herhangi bir değişiklik yapmadan önce daima temel performansı ölçün. Her değişiklikten sonra yeniden karşılaştırma yapın. Her seferinde tek bir değişiklik yapın.

Yeniden yüklemeden önce nginx -t ile doğrulayın. Kaynak çekişmesini önlemek için karşılaştırmaları ayrı bir makineden çalıştırın.

wrk, HTTP yük testi için standart bir araçtır:

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

Saniye başına istekleri, ortalama gecikmeyi, maksimum gecikmeyi ve aktarım hızını izleyin. Apache Bench, daha basit testler için kullanılır:

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

Sürekli izleme

Aktif bağlantıları gerçek zamanlı olarak izlemek için stub_status modülünü etkinleştirin curl http://localhost/nginx_status.

Gecikmelerin nerede oluştuğunu belirlemek için günlük biçiminize zamanlama değişkenleri ekleyin:

• $request_time toplam istek süresi için
• $upstream_connect_time arka uç bağlantı süresi için
• $upstream_response_time toplam arka uç işleme süresi için

Hata günlüklerini kontrol ederek tampon sorunlarını journalctl -u nginx --no-pager | grep "temporary file". Yanıtlar diske çarpıyorsa, proxy_buffers çok küçüktür. "Çok fazla açık dosya" hatalarını arayın; bu hatalar worker_rlimit_nofile artırılması gerektiğini gösterir.

Tamponlu günlük kaydı ile günlük I/O'sunu azaltın:

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

Yük testleri sırasında ss -tn state established dst [backend_ip] Yük testleri sırasında, bağlantıların yeniden kullanıldığını ve TIME_WAIT'te birikmediğini doğrulayın.

Yüksek performanslı iş yükleri için optimize edilmiş özel sunucular ve VPS barındırma hizmetleri için FDC Sunucuları'na bakın.