Sunucu Karşılaştırması ve Performans
Nginx mi Apache mi Daha Hızlı?
Nginx mi Apache mi sorusu genellikle yanlış kurulur. Soru "hangisi daha hızlı?" değil, "hangi yük tipinde hangisi daha az kaynak tüketir?" olmalıdır. İkisi de on yıllardır üretim ortamlarında çalışan, olgun yazılımlardır. Birinin diğerine mutlak üstünlüğü yoktur; fark, mimarinin belirli senaryolardaki davranışından kaynaklanır.
Yine de bazı farklar gerçek ve ölçülebilirdir. Nginx, yüksek eşzamanlılık altında bellek tüketimini düşük tutmakta öne çıkar. Apache ise yapılandırma esnekliği ve bazı barındırma ortamlarıyla uyumu açısından avantajlıdır. Bu farkların nereden geldiğini anlamak, sunucu seçimini rasgele değil ihtiyaca göre yapmanızı sağlar.
Her iki sunucunun mimarisine bakıp ardından belirli senaryolarda performans farkının gerçekte ne anlama geldiğini incelemek en doğru yaklaşım olacaktır.
İki farklı mimari anlayışı
Apache, her gelen isteği bir işlem (process) veya iş parçacığı (thread) ile karşılamak üzere tasarlanmıştır. Bu yaklaşım, 1990'larda web trafiğinin görece sınırlı olduğu dönemde oldukça işlevseldi. Her istek kendi bağımsız sürecinde çalışır, böylece bir isteğin çökmesi diğerlerini etkilemez. Ancak binlerce eşzamanlı bağlantı söz konusu olduğunda her bağlantı için ayrı bir süreç veya thread oluşturmak hem bellek hem de CPU açısından maliyetlidir.
Nginx farklı bir yoldan gider. Olay güdümlü (event-driven), bloklamayan (non-blocking) bir mimari kullanır. Tek bir çalışan süreç (worker process) binlerce bağlantıyı eşzamanlı olarak yönetebilir. Bir bağlantı I/O beklerken diğer bağlantılarla ilgilenmeye devam eder; süreç beklemez, bloklanmaz. Bu mimari, yüksek eşzamanlılıkta bellek tüketimini ciddi biçimde düşürür. 2009'da ortaya çıkan "C10K problemi" — 10.000 eşzamanlı bağlantıyı yönetme — tam olarak bu mimari fark üzerinden tartışılmıştır.
Apache'nin worker modelleri: prefork, worker, event
Apache'nin tek bir model sunmadığını bilmek önemlidir. Üç farklı MPM (Multi-Processing Module) seçeneği vardır. Prefork modeli her istek için ayrı bir process oluşturur; güvenli ama bellek açısından en maliyetli seçenektir. Worker modeli process sayısını azaltarak her süreç içinde çoklu thread kullanır; bellek tüketimi prefork'a göre düşer. Event modeli ise Apache'nin Nginx'e en yakın davrandığı seçenektir: keep-alive bağlantılarını ayrı bir thread havuzunda yönetir, aktif istekler için thread kullanımını optimize eder.
Event MPM ile Apache'nin performansı, benzer yapılandırmadaki Nginx'e önemli ölçüde yaklaşır. Ancak varsayılan olarak birçok dağıtım hâlâ prefork veya worker ile gelir. Dolayısıyla "Apache yavaştır" gözlemi çoğunlukla varsayılan MPM yapılandırmasından kaynaklanır; mimarinin kendisinden değil.
Statik içerik sunumunda fark
Nginx, statik dosyaları sunmakta son derece verimlidir. Dosyayı doğrudan disk üzerinden okuyup istemciye iletir; bu işlem sırasında PHP veya herhangi bir uygulama katmanını devreye sokmaz. Bellek tüketimi düşük, gecikme minimumdur. Saatte milyonlarca statik dosya isteğini işleyen bir CDN edge sunucusu düşünüldüğünde, bu verimlilik kritik hale gelir.
Apache da statik dosyaları doğrudan sunabilir; ancak .htaccess dosyaları aktifse Apache her istek için dizin hiyerarşisini kontrol etmek zorundadır. İstek gelen dizinden kök dizine kadar tüm .htaccess dosyaları okunur ve işlenir. Bu özellik esneklik sağlar — her dizin için ayrı yapılandırma yazılabilir — ama her istek için disk okuma maliyeti oluşturur. Yüksek trafikte bu ekstra okuma birikir. AllowOverride None direktifiyle .htaccess işleme devre dışı bırakıldığında Apache'nin statik içerik performansı önemli ölçüde artar.
Yüksek eşzamanlılıkta bellek tüketimi
100 eşzamanlı bağlantı için bellek tüketimi her iki sunucuda da yönetilebilirdir. Fark 1.000, 5.000 ya da 10.000 bağlantıya çıkıldığında belirginleşir. Apache prefork modunda her bağlantı yaklaşık 5–20 MB bellek tüketebilir; 5.000 bağlantı, 25–100 GB belleğe karşılık gelir ki bu çoğu sunucunun kapasitesini aşar. Worker modunda bu oran thread başına düşer ve daha makul kalır; event modunda ise Nginx'e benzer seviyelere gelir.
Nginx için eşzamanlı bağlantı sayısı bellek tüketimini doğrusal olarak artırmaz. Her bağlantı için ayrı bir süreç yoktur; worker process sayısı genellikle CPU çekirdek sayısına eşit tutulur. Bağlantı sayısı arttıkça işletim sistemi düzeyindeki soket yönetimi devreye girer. Bu nedenle Nginx'in yüksek eşzamanlılıkta bellek ayak izi çok daha öngörülebilirdir. TTFB açısından bu fark doğrudan görünmez olsa da sunucu hafızası tükendikçe swap'a düşen bir sistem gecikmeyi kaçınılmaz olarak artırır.
PHP entegrasyonu: mod_php karşısında PHP-FPM
Apache'nin geleneksel PHP entegrasyonu mod_php ile yapılır. Bu yaklaşımda PHP yorumlayıcısı doğrudan Apache sürecinin içine gömülüdür. Her Apache worker süreci ya da thread'i tam bir PHP ortamı taşır — bu ortamı kullanmasa bile. Statik bir CSS dosyasını sunan Apache worker'ı da bellekte PHP yorumlayıcısını barındırır. Bu, gereksiz bellek israfıdır.
Nginx ise mod_php'yi desteklemez. PHP için PHP-FPM (FastCGI Process Manager) kullanmak zorunludur. PHP-FPM ayrı bir servis olarak çalışır; Nginx PHP isteğini FastCGI üzerinden bu servise yönlendirir, yanıtı alır ve istemciye iletir. Bu ayrışma önemli avantajlar getirir: PHP worker havuzu bağımsız olarak ölçeklenebilir, PHP çökmesi web sunucusunu etkilemez, statik içerik sunan Nginx worker'ları PHP yükü taşımaz. Apache da PHP-FPM ile kullanılabilir; bu yapılandırmada mod_php'ye kıyasla belirgin iyileşme görülür.
Yapılandırma esnekliği ve .htaccess faktörü
Apache'nin .htaccess desteği, paylaşımlı barındırma ortamlarında büyük bir avantajdır. Her kullanıcı kendi dizin yapılandırmasını sunucu yöneticisine gerek duymadan değiştirebilir; URL yönlendirme kuralları, erişim kısıtlamaları ve başlık manipülasyonu kolayca uygulanabilir. WordPress gibi platformlar Apache'nin mod_rewrite özelliğini uzun süre varsayılan olarak kullanmıştır; .htaccess dosyaları bu yüzden birçok hazır çözüm tarafından otomatik oluşturulur.
Nginx'te .htaccess eşdeğeri yoktur. Tüm yapılandırma merkezi konfigürasyon dosyalarında yapılır ve her değişiklik için reload gerekir. Bu, paylaşımlı barındırma ortamlarında ciddi bir kısıtlamadır; ancak tek kiracılı veya konteyner tabanlı yapılarda tam tersi bir avantaja dönüşür. Merkezi yapılandırma, sürüm kontrolüne alınabilir, otomatik dağıtım süreçlerine entegre edilebilir ve hata ayıklanması daha kolaydır.
Keep-alive bağlantıları ve sunucu davranışı
HTTP keep-alive, aynı TCP bağlantısı üzerinden birden fazla istek gönderilmesini sağlar. Tarayıcı sayfayı yüklerken CSS, JS ve görsel dosyalarını aynı bağlantıdan talep edebilir; bu TCP handshake maliyetini düşürür. Ancak keep-alive bağlantısı açık tutmak demek, sunucu kaynağı o bağlantı için ayrılmış demektir.
Apache prefork modunda açık bir keep-alive bağlantısı için tam bir process ayrılmış kalır — istek gelmese bile. Bu, boşta bekleyen onlarca veya yüzlerce process oluşturabilir. Nginx'in event-driven mimarisi bu sorunu doğası gereği çözer: boşta bekleyen bağlantı worker'ı bloklamaz, yeni istekler için kapasite açık kalır. Tarayıcı cache bu etkiyi azaltır — tekrar ziyarette pek çok kaynak zaten cache'de olduğundan bağlantı sayısı düşer — ama ilk ziyarette fark daha belirgindir.
Reverse proxy senaryosunda sunucu seçimi
Çoğu modern yapıda web sunucusu doğrudan istemciye değil, önünde bir CDN veya reverse proxy katmanı aracılığıyla hizmet verir. Bu mimaride web sunucusunun istemciye maruz kalan yüksek eşzamanlılık yükü azalır; CDN veya proxy katmanı büyük bölümünü absorbe eder. Dolayısıyla "Nginx mi Apache mi?" sorusu, bu yapılarda daha az kritik hale gelir. Sunucu büyük ölçüde PHP veya uygulama işlemlerini çalıştırmakla görevlidir; eşzamanlı bağlantı yönetimindeki mimari fark çok da belirleyici olmaz.
Bununla birlikte kaynak kısıtlamasının yüksek olduğu VPS veya küçük bulut örnekleri üzerinde, aynı iş yükü için Nginx genellikle daha az bellek tüketir. 1 GB RAM'e sahip bir sunucuda Nginx + PHP-FPM kombinasyonu, Apache prefork + mod_php kombinasyonuna kıyasla belirgin biçimde daha fazla eşzamanlı isteği karşılayabilir.
SSL/TLS işleme kapasitesi
Her iki sunucu da HTTPS bağlantılarını OpenSSL kütüphanesi üzerinden yönetir; bu açıdan temel bir fark yoktur. Ancak yüksek eşzamanlılıkta TLS handshake işlemlerini yönetme biçimi yine mimari farklılığa döner. Nginx'in non-blocking yapısı, TLS handshake'leri beklerken diğer bağlantıları işlemeye devam edebilmesini sağlar. Apache event MPM bu konuda benzer bir davranış sergiler; prefork ise her handshake için bir process bloklar.
TLS 1.3'ün yaygınlaşmasıyla handshake süresi azaldı; session resumption mekanizmaları tekrarlayan bağlantılarda yeniden handshake maliyetini düşürüyor. Bu gelişmeler iki sunucu arasındaki SSL işleme farkını pratik olarak küçülttü. HTTP/3 ile birlikte QUIC protokolü devreye girdiğinde tablo daha da değişiyor: Nginx QUIC desteğini aktif olarak geliştirirken Apache'nin bu alandaki ilerleme hızı daha yavaş kaldı.
Modül ekosistemi ve hazır çözüm uyumluluğu
Apache'nin modül ekosistemi son derece geniştir. mod_rewrite, mod_security, mod_pagespeed ve onlarca başka modül onlarca yıllık birikim sonucu olgunlaşmıştır. Birçok hazır yazılım — özellikle eski PHP uygulamaları ve WordPress gibi CMS'ler — kurulum belgelerinde Apache varsayılan olarak gösterir; .htaccess dosyaları zaten hazır gelir.
Nginx ekosistemi daha gençtir ancak hızla büyümüştür. OpenResty (Nginx + Lua) gibi çözümler Nginx'in üzerine güçlü uygulama katmanları inşa etmeyi mümkün kılar. Nginx Plus ticari versiyonu gelişmiş load balancing, health check ve dashboard özellikleri sunar. Açık kaynak Nginx de büyük ölçekte üretimde yeterli kalmakla birlikte, karmaşık dinamik yönlendirme senaryolarında Apache'nin mod_rewrite esnekliğine tam olarak denk gelmez.
Hangi senaryo hangisini gerektirir?
Paylaşımlı barındırma ortamı, eski PHP uygulamaları veya .htaccess bağımlı hazır yazılımlar kullanılıyorsa Apache daha az sürtünmeyle çalışır. Apache'nin yapılandırma esnekliği, farklı müşterilerin aynı sunucuda izole yapılandırma yapabilmesi gereken ortamlarda vazgeçilmez olabilir.
Öte yandan statik içerik ağırlıklı bir yapı, yüksek eşzamanlılık gerektiren bir API sunucusu veya bellek kısıtlı bir VPS varsa Nginx + PHP-FPM kombinasyonu daha verimli çalışır. Konteyner tabanlı yapılarda merkezi yapılandırma gerekliliği bir kısıt değil, bir avantaj haline gelir. Performans testleri genellikle Nginx'in bu senaryolarda daha düşük bellek kullanımıyla daha fazla eşzamanlı isteği karşıladığını gösterir; ancak farkın büyüklüğü iş yüküne ve yapılandırmaya göre değişir.
Benchmark'ların yanıltıcı yönü
"Nginx Apache'den %X daha hızlı" gibi ifadeler çoğunlukla belirli bir yük tipi, belirli bir yapılandırma ve belirli bir donanım için geçerlidir. Ham HTTP benchmark araçları genellikle basit statik dosya testleri yapar; bu testlerde Nginx'in avantajı net görünür. Ancak gerçek dünya trafiğinde PHP işleme ağırlıklı bir uygulamada bottleneck PHP-FPM havuzunda ya da veritabanında olacaktır; web sunucusunun kendi katkısı ihmal edilebilir düzeye iner.
Lighthouse gibi araçlarla ölçülen kullanıcı deneyimi metrikleri, web sunucusu seçiminden çok uygulama kodu kalitesi, önbellekleme stratejisi ve ağ gecikmesiyle şekillenir. Web sunucusu değiştirmek tek başına LCP'yi ya da INP'yi dramatik biçimde değiştirmez. Asıl fark, sunucunun ölçekleme sınırlarına ulaştığı yoğun trafik dönemlerinde ortaya çıkar.
Nginx ile Apache arasındaki tercih, "hangisi daha iyi?" sorusuna değil "bu iş yükü için hangisi daha uygun?" sorusuna yanıt arar. Nginx, yüksek eşzamanlılık ve kaynak verimliliği gerektiren senaryolarda öne çıkar; Apache ise yapılandırma esnekliği ve geniş ekosistem desteği açısından avantajlıdır.
Pratikte pek çok yapı ikisini birden kullanır: Nginx reverse proxy olarak öne geçer, Apache ya da PHP-FPM arka uçta uygulama katmanını yönetir. Bu hibrit mimari her iki tarafın güçlü yönlerinden yararlanır. Seçim yaparken benchmark'lara değil, gerçek trafik desenine, mevcut uygulama bağımlılıklarına ve ekibin yapılandırma konusundaki deneyimine bakılmalıdır.
Sunucu değiştirmeyi düşünüyorsanız önce darboğazın gerçekten web sunucusunda olduğunu doğrulamak gerekir. Çoğu durumda yavaşlama veritabanında, önbelleksiz dinamik sayfada ya da ağır bir üçüncü taraf kaynağındadır. Doğru ölçüm yapılmadan gerçekleştirilecek sunucu göçü emek ve risk taşır ama beklenen performans kazanımını getirmeyebilir.