Nginx ile Apache arasındaki mimari fark nedir?

Nginx ile Apache arasındaki mimari fark nedir?​

Nginx ile Apache arasındaki temel mimari fark, istemci bağlantılarını ve istekleri ele alma biçimleridir. Nginx, olay tabanlı ve eşzamansız bir çalışma modeliyle çok sayıda bağlantıyı az sayıda çalışan süreçle yönetmeye odaklanır. Apache ise seçilen MPM modeline göre farklı bağlantı yönetimi kullanır; yalnız “her bağlantıya bir süreç” şeklinde tanımlanamaz. Her iki sunucu da modüllerle genişletilebilir. Bu nedenle Nginx genellikle statik dosya sunumu ve ters vekil görevinde öne çıkar; Apache ise uygulama uyumluluğu, modüller ve dizin bazlı yapılandırmada daha esnektir.

Mimari fark nasıl çalışır?​

Nginx'in ana çalışma modeli bir olay döngüsüdür. Bir çalışan süreç, ağ bağlantılarının hazır olmasını bekler ve işi bloklamadan sırayla işler. Yavaş bir istemci veya çok sayıda açık bağlantı, her bağlantı için ayrı bir işletim sistemi süreci oluşturulmasını gerektirmez. Bu yapı Nginx'i statik dosya sunma, bağlantı sonlandırma, yük dengeleme ve ters vekillik için uygun kılar.

Apache mimarisi seçilen MPM'e bağlıdır: prefork süreç, worker süreç ve iş parçacıkları kullanır. event MPM ise keep-alive gibi bazı beklemeleri listener iş parçacıklarına aktararak işlem yapan worker'ları serbest bırakabilir. Bu nedenle Apache ile Nginx arasındaki farkı olay tabanlı/olay tabanlı değil şeklinde kesin ikiliğe indirmeyin. Apache'nin önemli farkı, istek işleme zincirinin çok sayıda modülle genişletilebilmesidir. Kimlik doğrulama, URL yeniden yazma, erişim kontrolü ve uygulama entegrasyonu sunucuya daha doğrudan eklenebilir.

PHP gibi uygulama kodları iki sunucuda da genellikle ayrı bir uygulama süreciyle çalıştırılır. Örneğin Nginx, PHP dosyasını kendisi yorumlamak yerine isteği PHP-FPM'e FastCGI üzerinden iletebilir. Apache de PHP-FPM kullanabilir veya kurulumun tasarımına göre başka bir çalışma modeli seçebilir. Dolayısıyla fark yalnızca “PHP'yi hangi sunucu çalıştırıyor?” sorusuyla açıklanamaz; bağlantı yönetimi, yapılandırma modeli ve modül mimarisi birlikte değerlendirilmelidir.

Somut örnek​

Varsayımsal olarak example.com üzerinde bir WordPress sitesi, görseller ve CSS dosyaları, ayrıca PHP tabanlı dinamik sayfalar barındırsın. Nginx bu senaryoda görsel ve CSS isteklerini doğrudan diskten sunabilir; PHP gerektiren istekleri ise PHP-FPM'e aktarabilir. Apache de aynı ayrımı yapabilir, ancak mevcut Apache modülleri ve uygulamanın mevcut modül ve dizin kuralları Apache yapılandırmasında korunabilir. .htaccess ancak sunucu izin veriyorsa etkilidir; ana yapılandırmaya erişimde her dizine .htaccess eklemek zorunlu değildir.

Bir istemci uzun süre açık kalan bağlantılar kuruyorsa Nginx'in olay tabanlı modeli kaynak kullanımını daha öngörülebilir hale getirebilir. Buna karşılık uygulama, farklı klasörlerde bulunan .htaccess kurallarına veya Apache modüllerine bağımlıysa Apache'yi değiştirmek daha fazla uyarlama gerektirebilir. Bu bir hız garantisi değildir; sonuç, uygulama koduna, önbelleğe, disk ve ağ yapısına ve yapılandırmaya bağlıdır.

Hangi mimariyi seçmeli?​

Kararı yalnızca sunucu adlarına göre vermek yerine aşağıdaki sırayla değerlendirin:

1. Uygulamanın Apache'ye özgü modül veya .htaccess gereksinimi olup olmadığını belirleyin. Böyle bir bağımlılık varsa Apache ile doğrudan çalışmak veya Nginx önünde Apache kullanmak daha az uyarlama gerektirebilir.
2. Statik içerik, ters vekil, TLS sonlandırma veya birden fazla uygulama sunucusuna dağıtım öncelikliyse Nginx'in olay tabanlı yapısını değerlendirin.
3. Uygulamanın PHP, Python veya başka bir çalışma zamanı ile nasıl iletişim kuracağını belirleyin. Web sunucusu ile uygulama sunucusunun görevlerini birbirine karıştırmayın.
4. Seçtiğiniz yapıyı test ortamında istek günlükleri, hata günlükleri, açık bağlantılar ve uygulama yanıtlarıyla doğrulayın. Yalnızca tek bir sentetik hız ölçümüne göre karar vermeyin.
5. Geçiş yapıyorsanız URL yeniden yazma, istemci IP'sinin aktarılması, yükleme sınırları ve hata sayfaları gibi davranışların eski yapıyla aynı olduğunu kontrol edin.

Aşağıdaki özet, ilk mimari karar için kullanılabilir:


Tablodaki seçimler kesin performans sonucu değil, mimari başlangıç noktalarıdır. En doğru karar, uygulamanın bağımlılıklarını ve gerçek trafik biçimini test ederek verilir.

Sık yapılan hatalar​

En yaygın hata, Nginx'in her durumda Apache'den hızlı veya Apache'nin her durumda daha uyumlu olduğunu varsaymaktır. Web sunucusu yalnızca bir katmandır; yavaş sorgular, hatalı önbellekleme, uygulama süreçlerinin yetersizliği veya disk gecikmesi toplam sonucu belirleyebilir.

Bir diğer hata, Apache'deki .htaccess kurallarını Nginx yapılandırmasına doğrudan kopyalamaya çalışmaktır. Bu dosyalar aynı sözdizimini ve aynı çalışma modelini kullanmaz. Geçişte kuralların amacı yeniden ifade edilmeli, ardından normal sayfa, var olmayan sayfa, yükleme ve yönetim istekleri ayrı ayrı test edilmelidir.

Sık sorulan sorular​

Nginx ve Apache aynı sunucuda birlikte kullanılabilir mi?​

Evet. Genellikle dışarıya bakan katman Nginx olur ve uygun istekleri Apache'ye ters vekil olarak iletir. Ancak portlar, istemci IP aktarımı, günlükler ve hata yanıtları iki katmanda da tutarlı yapılandırılmalıdır.

Nginx Apache'nin yerine uygulama sunucusu mudur?​

Hayır. Nginx çoğunlukla HTTP bağlantılarını, statik dosyaları ve vekil trafiğini yönetir. PHP-FPM veya başka bir uygulama çalışma zamanı gibi ayrı bir bileşen, dinamik uygulama kodunu çalıştırabilir.

Seçimden önce ilk kontrol ne olmalı?​

Önce uygulamanın .htaccess, Apache modülleri veya Apache'ye özgü dağıtım varsayımlarına bağlı olup olmadığını kontrol edin. Bu bağımlılıklar yoksa trafik modeli ve işletim kolaylığına göre iki mimariyi test edebilirsiniz.