Nginx vs Apache: Web Sunucu Karşılaştırma Rehberi

Bir web sitesinin trafiği artmaya başladığında, altyapıyı hangi web sunucusunun taşıdığı gerçek bir fark yaratır. Nginx ve Apache, internetin büyük bölümüne güç veren iki isim; ama aynı işi çok farklı biçimde yapıyorlar. Bu yazıda ikisinin mimari farkını, gerçek yapılandırma dosyalarıyla ve hangi senaryoda hangisini seçmeniz gerektiğini somut örneklerle ele alıyorum.

"Hangisi mutlak olarak daha iyi" sorusunun net bir cevabı yok. Trafik profiliniz, sunucu kaynaklarınız ve ekibinizin deneyimi, doğru seçimi belirleyen asıl etkenler.

Apache nasıl çalışır

Apache, gelen her bağlantı için ayrı bir süreç veya iş parçacığı (thread) oluşturan bir mimariye sahip. Bu davranış prefork veya worker gibi MPM (Multi-Processing Module) modlarıyla kontrol edilir; yeni bir istek geldiğinde Apache bu isteği işlemek üzere bir işçi ayırır.

# apache2.conf içinde MPM ayarı örneği
<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxRequestWorkers   150
    MaxConnectionsPerChild 0
</IfModule>

MaxRequestWorkers değeri, Apache'nin aynı anda işleyebileceği istek sayısının üst sınırını belirler. Bu sınıra ulaşıldığında yeni istekler kuyrukta bekler. Yüksek trafikli bir sitede bu değeri düşük bırakmak, sunucuda boş kaynak olsa bile kullanıcılara "sunucu meşgul" hatası döndürür.

Apache'nin gücü .htaccess dosyalarından geliyor; her dizin kendi kurallarını tanımlayabilir. Paylaşımlı hostingde her kullanıcının kendi dizinini yönetebilmesi bu sayede mümkün. Ancak her istekte .htaccess dosyasını diskten okumak ek bir performans maliyeti getiriyor.

Nginx nasıl çalışır

Nginx, olay tabanlı (event-driven) ve asenkron bir mimari kullanıyor. Tek bir işçi süreci, her bağlantı için ayrı bir iş parçacığı açmadan binlerce bağlantıyı aynı anda işleyebilir. Nginx'in az bellekle yüksek eşzamanlılığı kaldırabilmesinin temel nedeni bu.

# nginx.conf içinde worker ayarı örneği
worker_processes auto;
events {
    worker_connections 4096;
}

worker_connections, her işçi sürecinin kaç eşzamanlı bağlantı işleyebileceğini belirler. worker_processes auto ise Nginx'e, sunucudaki CPU çekirdek sayısı kadar işçi süreci başlatmasını söyler. Bu iki ayar birlikte, Nginx'in aynı donanımda Apache'den çok daha fazla eşzamanlı bağlantıyı düşük gecikmeyle karşılamasını sağlıyor.

Nginx, statik dosya sunmada da doğrudan avantajlı. sendfile on; direktifi, dosyayı önce uygulama belleğine kopyalamadan doğrudan disk ile ağ arasında aktarır. Bu, büyük görsel veya video dosyaları sunan sitelerde ölçülebilir bir hız farkı yaratır.

Yapılandırma dosyası farkları

Apache dizin bazlı yapılandırmaya izin verirken, Nginx merkezi bir yapılandırma dosyası kullanıyor ve çalışma zamanında .htaccess benzeri bir dosya okumuyor. Nginx'in her istekte ekstra disk okuması yapmamasının nedenlerinden biri bu.

Aynı işi, bir dizine yönlendirme kuralını, iki sunucuda karşılaştırmak farkı netleştiriyor:

# Apache .htaccess
RewriteEngine On
RewriteRule ^eski-sayfa$ /yeni-sayfa [R=301,L]

# Nginx server bloğu içinde
location = /eski-sayfa {
    return 301 /yeni-sayfa;
}

Nginx'teki yönlendirme kuralı, sunucu başladığında bir kez yüklenir ve bellekte kalır. Apache'deki .htaccess kuralı ise, yapılandırmaya bağlı olarak, her istekte yeniden okunabilir. Bu fark küçük sitelerde hissedilmez; binlerce eşzamanlı istek alan bir sitede toplam gecikmeye eklenir.

Performans karşılaştırması

Statik dosya sunma ve yüksek eşzamanlı bağlantı senaryolarında Nginx genellikle daha az kaynakla daha fazla isteği karşılıyor. Dinamik PHP içeriği üretme tarafında ise fark, kullanılan PHP işleme yöntemine bağlı. Apache mod_php ile PHP'yi doğrudan kendi içine gömerken, Nginx PHP kodunu çalıştırmıyor; isteği PHP-FPM adlı ayrı bir işleme havuzuna iletiyor.

location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
}

Bu ayrım aslında bir avantaj: PHP-FPM havuzunu Nginx'ten bağımsız olarak ayarlayıp yeniden başlatabilirsiniz, bu da bakım sırasında kesinti süresini azaltır. Apache tarafında da mod_php yerine PHP-FPM kullanmak mümkün ve pek çok modern kurulum bunu tercih ediyor.

Hangi senaryoda hangisi

Yüksek trafikli bir haber sitesi, çok sayıda statik görsel sunan bir e-ticaret sitesi veya API gateway olarak çalışacak bir sistem için Nginx doğal seçim. Eşzamanlı bağlantı sayısı arttıkça, Apache'nin süreç bazlı yaklaşımı bellek tüketimi açısından dezavantaja dönüşüyor.

Paylaşımlı hosting ortamları, her kullanıcının kendi .htaccess dosyasını yönetmesi gereken senaryolar veya çok çeşitli, dizin bazlı özel kurallar gerektiren siteler için Apache hâlâ pratik bir seçim. Apache'nin modül ekosistemi, özel işleme gerektiren eski uygulamalarla uyumluluk açısından da avantaj sağlayabilir.

Kısa bir karar özeti çıkarmak gerekirse:

• Yüksek eşzamanlı bağlantı ve statik içerik ağırlıklı bir site için Nginx
• Dizin bazlı özel yapılandırma ve paylaşımlı hosting için Apache
• Her iki ihtiyacı da karşılamak için Nginx + Apache hibrit kurulumu

Pek çok üretim ortamı bu üçüncü yolu seçiyor: Nginx ön planda ters proxy ve statik dosya sunucusu olarak çalışırken istekleri arkadaki Apache'ye yönlendirir.

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

Bu düzende Nginx statik dosyaları doğrudan kendisi sunar, yalnızca dinamik istekleri arka plandaki Apache'ye iletir. Her iki sunucunun güçlü yanından aynı anda faydalanırsınız.

Önbellekleme ile performans artırma

Tarayıcı önbelleklemesi doğru yapılandırıldığında, tekrar eden ziyaretlerde sunucuya giden istek sayısını belirgin biçimde azaltır. Nginx'te bu, dosya uzantısına göre expires direktifiyle tanımlanır.

location ~* \.(jpg|jpeg|png|gif|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

Bu kural, görsel ve statik dosyaların tarayıcıda 30 gün boyunca saklanmasını söyler; kullanıcı siteyi tekrar ziyaret ettiğinde bu dosyalar sunucudan yeniden indirilmez. Apache'de aynı davranış mod_expires modülüyle, .htaccess veya sanal host tanımı içinde benzer bir mantıkla sağlanır.

Sunucu tarafı önbellekleme için Nginx'in proxy_cache direktifi, arka uçtan gelen dinamik yanıtları bile kısa süreliğine önbelleğe alabilir. Bu, veritabanı sorgusu ağır olan sayfalarda sunucu yükünü ciddi biçimde azaltır. Apache'de benzer bir işlevi mod_cache üstlenir, ancak yapılandırması Nginx'e göre daha fazla modül bağımlılığı gerektirir.

Güvenlik yapılandırması

Her iki sunucuda da SSL/TLS kurulumu benzer mantıkla ilerler; sertifika dosyalarının yolu gösterilir ve şifreleme protokolleri kısıtlanır. Let's Encrypt gibi ücretsiz sertifika sağlayıcılarının certbot aracı, hem Nginx hem Apache için otomatik yapılandırma eklentisi sunar.

sudo certbot --nginx -d alanadiniz.com

Hız sınırlama (rate limiting), kaba kuvvet saldırılarına karşı temel bir savunma. Nginx'te bu, birkaç satır direktifle tanımlanır:

limit_req_zone $binary_remote_addr zone=giris:10m rate=5r/s;
location /giris {
    limit_req zone=giris burst=10;
}

Bu kural, /giris yoluna aynı IP'den saniyede 5'ten fazla istek gelmesini engeller; kısa patlamalarda 10 isteğe kadar tolerans tanır. Apache'de benzer bir sınırlama mod_evasive modülüyle sağlanır, ancak kurulumu Nginx'in yerleşik direktiflerine göre biraz daha fazla adım gerektirir.

Sunucu yazılımını güncel tutmak, seçtiğiniz sunucudan bağımsız olarak en temel güvenlik adımı. Bilinen bir güvenlik açığı yamalandıktan sonra bile güncellenmemiş bir sürüm hâlâ saldırı yüzeyi oluşturur. HTTP güvenlik başlıklarını (X-Content-Type-Options, X-Frame-Options) ayarlamak, hem Nginx hem Apache'de birkaç satırlık bir ekleme ile mümkün ve tarayıcı seviyesinde ek bir koruma katmanı sağlar.

Nginx'in resmi belgelerine nginx.org dokümantasyonu üzerinden, Apache'nin resmi belgelerine ise Apache HTTP Server dokümantasyonu üzerinden ulaşabilirsiniz. Her iki proje de yapılandırma referanslarını ve güvenlik tavsiyelerini düzenli olarak günceller.

Yazan Celil Uyanikoglu

25 yıldır bilgi işlem piyasasında farklı dallarda uzmanlaşan bir Bilgisayar Mühendisi