Apache ve Nginx: Sizin İçin En İyi Web Sunucusu Hangisi? 

İnternet, bugün bildiğimiz şekliyle, 90'larda küresel "fethine" başladı. Tüm "Web" protokolü, belirli bir web adresinden bir belge talep eden bir ziyaretçi olarak özetlenebilir, DNS ve IP sistemi bu talebi doğru bilgisayara iletir. İstenen web sayfasını barındıran bu bilgisayar, web sayfasını ziyaretçiye geri "sunacaktır". Ziyaretçilere farklı web sayfaları sunabilmek için, "servis" makinesinin bir sunucu programına ihtiyacı vardır. Nginx vs Apache gibi yazılımlar istekleri ele alır, analiz eder ve ardından ilgili belgeleri ziyaretçinin tarayıcısında görüntülenmek üzere geri verir. 

Apache ve Nginx: Sizin İçin En İyi Web Sunucusu Hangisi? 

 

Nginx ve Apache 

Nginx ve Apache, web sayfalarını bir kullanıcının tarayıcısına sunmak için kullanılan popüler web sunucularıdır. Hızlı istatistikler: 

  

  • Apache ilk olarak 1995'te piyasaya sürüldü, ardından 2004'te Nginx çıktı. 
  • Her ikisi de dünyanın dört bir yanındaki büyük Fortune 500 şirketleri tarafından kullanılmaktadır. 
  • Nginx pazar payı yıllardır istikrarlı bir şekilde büyüyor. 
  • Bazı durumlarda, Nginx performans açısından rekabet üstünlüğüne sahiptir. 

 

 

Apaçi 

İlk piyasaya çıktığından beri ilk olarak Apache'ye dalacağız. 

  

İnternetin ilk birkaç yılında Tim Berners-Lee’nin CERN httpd ve NCSA HTTPd’inden sonra, Apache - ilk olarak 1995’te piyasaya çıktı - hızla piyasayı fethetti ve dünyanın en popüler web sunucusu oldu. Bugünlerde, hala bu piyasa konumunda, ancak çoğunlukla eski nedenlerden dolayı. Apache, Apache lisansı altında Apache Vakfı tarafından geliştirilmekte ve sürdürülmektedir. 

  

Apache'nin adını nasıl aldığına dair iki farklı hikaye var. Bir sürüm, adın ünlü Kızılderili mirasından geldiğini söylerken, diğeri adın bir dizi yazılım yamasını takip eden "düzensiz bir sunucuda" kelime oyunu olduğunu söylüyor. 

 

Linux 

Apache'nin büyük pazar payı, kısmen Red Hat / Centos ve Ubuntu gibi tüm büyük Linux dağıtımlarıyla önceden yüklenmiş olarak gelmesinden kaynaklanmaktadır. 

 

Ubuntu default page

Ubuntu varsayılan sayfası 

  

Apache'nin Linux dünyasındaki önemli rolünün bir örneği, sunucu işlem adının HTTPd olması ve Apache'yi web sunucusu yazılımıyla eşanlamlı hale getirmesidir. 

Apache’nin yaygınlaşmasının bir kısmı yapılandırma sistemi ve .httaccess dosyasıdır. 

 

 

.htaccess 

Apache, yapılandırması için .htaccess kullanır. Apache'nin gelen istekleri işleme şeklini yapılandırmada büyük esneklik sağladığı için, bu dosyanın nasıl yapılandırılacağı, düzenleneceği ve bu dosyayla nasıl çalışılacağı hakkında birçok öğretici vardır. Bazı örnekler şunlardır: farklı yeniden yönlendirme kurallarımaksimum yükleme dosyası boyutları, URL yeniden yazmaları, bellek sınırları, dizin koruması (htpasswd), sona erme başlıkları, önbellek kontrol başlıklarıkodlama başlıkları, tanımlama bilgileri, sorgu dizesi işlemleri. 

  

Öte yandan Kinsta, .htaccess dosyalarını desteklemeyen Nginx'i kullanır. Ancak, .htaccess dosyalarınızdaki ayarlar ve kurallar kolayca Nginx’in kendi yeniden yazma kuralı sözdizimine "çevrilebilir". 

  

Apache'nin ana "Artılarından" biri, sunucu kökünde - ana web sitesi dizini - dizin ağacındaki her düzey veya dizinin kendi yapılandırmasına sahip kendi .httaccess dosyasına sahip olabilmesidir. 

  

Paylaşılan barındırma sağlayıcıları için bu bir hayal çünkü aynı makinedeki yüzlerce kullanıcıya web sitelerinin diğerlerini etkilemeden nasıl sunulacağını yapılandırmanın bir yolunu sağlayabilirler. Müşteriler, küresel sunucu yapılandırmasına asla dokunmadan, kısıtlı bir paylaşılan barındırma ortamında birçok ayrıntıyı yapılandırabilir. 

 

Resmi belgelerin dediği gibi: 

  

"Genel olarak, .htaccess dosyalarını yalnızca ana sunucu yapılandırma dosyasına erişiminiz olmadığında kullanmalısınız." 

  

Ancak bu esneklik, ".htaccess dosyalarına izin vermek, onları gerçekten kullansanız da kullanmasanız da, bir performans düşüşüne neden olur!" 

  

.Htaccess dosyaları her etkinleştirildiğinde, Apache, sunucunun kök dizinine kadar istenen URL veya dosyadan tüm dizin ağacını, sunucunun kök dizinine kadar tüm üst düzeylerden geçmeli ve ardından bunları her istek için yüklemelidir. Daha sonra bu dosyaları işlemesi ve bu şekilde yapılandırılan dizinlerin her biri için kendini yeniden yapılandırması gerekir. 

  

WordPress web siteleri ile işler gerçekten karmaşıklaşabilir. Tipik bir WordPress web sitesinde farklı dizinlerden yüzlerce istek olabilir. 

  

/ Wp-content / uploads / yyyy / mm türündeki dizinlerden, genellikle tek bir sayfa yüklemesinde birden çok istek alır ve genellikle farklı ay dizinleri oluşturur. Sonra / wp-content / themes / parent-theme statik kaynaklar, / wp-content / themes / child-theme kaynakları olacaktır: bunlar javascript, css dosyaları, resimler içerecektir. 

  

Daha sonra, düzinelerce eklenti alt dizininden yüklenen statik dosyalara sahip / wp-content / eklentileri de olacaktır. Bu kaynakların her biri için Apache, yapılandırmayı aramak için tüm ağacını geçmek zorundadır. 

  

Bir analiz, paylaşılan ana bilgisayarlardaki web siteleri için oldukça yaygın olan tipik bir WordPress kurulumunun 42 ayrı .htaccess yürütmesi ve .htaccess dosyası için 249 ayrı görünüm içereceğini göstermiştir. 

  

Bu sadece bir web sunucusu seviyesindedir. Ziyaretçinin, veritabanı sorgusunu oluşturmak ve web sayfasını bir araya getirip ziyaretçiye göndermek için MySQL'e vermek için PHP işleminin tüm WordPress çağrı yığınını yürütmesini beklemesi gerekir. 

 

 

Modüller 

Apache'yi popüler yapan bir diğer şey de dinamik modül sistemidir. 

  

Modüller - kullanıcıların web sunucusu işlevselliğini genişletmelerine olanak tanıyan bir özellik olarak - hem Nginx'te hem de Apache'de mevcuttur. Apache, kullanıcıların, web sunucusu zaten kurulup dağıtıldıktan sonra modülleri gerektiği gibi etkinleştirip / devre dışı bıraktıktan sonra yüklemelerine izin verir. Debian tabanlı dağıtımlar, herhangi bir yapılandırma dosyasını düzenlemek zorunda kalmadan bu modüllere izin veren ve devre dışı bırakan komutlara sahiptir: a2enmod ve a2dismod. 

  

Apache standardının bir parçası olarak gelen resmi modül listesi buradadır ve bunlar sıkıştırma, şifreleme dağıtımı, günlük kaydı, yeniden yönlendirmelerden düzenleme istekleri ve gelişmiş sözdizimi ile yanıtlar gibi daha gelişmiş şeylere kadar birçok şeyi içerir. 

 

 

Nginx 

Nginx (nginx veya NGINX olarak da yazılır), Rus geliştirici Igor Sysoev tarafından ilk kez halka açık olarak yayınlandığı 2004 yılında sahneye çıktı. Nginx’in proje yöneticisi Owen Garrett'ın dediği gibi: 

  

"Nginx, özellikle Apache web sunucularının performans sınırlamalarını ele almak için yazılmıştır." 

  

Sunucu ilk olarak 2002 yılında rambler.ru web sitesi için bir ölçekleme aracı olarak oluşturuldu. İki sürüm halinde gelir: BSD tipi lisanslı açık kaynak ve destek ve ek kurumsal özelliklerle Nginx Plus. 

  

Yayınlandıktan sonra, Nginx çoğunlukla statik dosyalar sunmak için ve Apache kurulumlarının önünde bir yük dengeleyici veya ters proxy olarak kullanıldı. Web geliştikçe ve bununla birlikte her son hız düşüşünü ve donanım kullanım verimliliğini sıkıştırma ihtiyacı arttıkça, daha olgun bir yazılım sayesinde daha fazla web sitesi Apache'yi tamamen Nginx ile değiştirmeye başladı. 

 

NGINX Inc acquired by F5 Networks

NGINX Inc, F5 Networks tarafından satın alındı 

  

Mart 2019'da Nginx Inc, F5 Networks tarafından 670 milyon dolara  satın alındı. O sırada Techcrunch'ın bildirdiğine göre, Nginx sunucusu "yaklaşık 1.500 ödeme yapan müşteriyle 375 milyon web sitesini" güçlendiriyordu. 

  

W3techs'den alınan verilere göre, Nginx'in pazar payı istikrarlı bir şekilde büyüyor, Apache'yi zorla ve ilk etaptan tahttan indiriyor: 

 

Web server usage

Web sunucusu kullanımı 

  

Bu veriler, küresel olarak genel web sunucularıyla ilgilidir, ancak ilk bir milyon web sitesinin örneğini alırsak, Nginx bir süredir oradaydı: 

 

Percentage of websites using Nginx

Nginx kullanan web sitelerinin yüzdesi 

  

Google Arama Trendleri bu gerçeği de yansıtıyor gibi görünüyor: 

 

Google Search Trends: Nginx vs Apache

Google Arama Trendleri: Nginx ve Apache 

  

Netcraft araştırması, Apache'nin Nisan 2019'da Nginx tarafından geride bırakıldığını gösteriyor . 

  

 

Nginx Yapılandırması 

Nginx'in Apache gibi bir yapılandırma sistemi yoktur, bu nedenle çok daha verimli ve hızlı olmasına rağmen, perakende barındırma sağlayıcılarında yaygın olarak kullanılmamaktadır. Paylaşılan ortamlarda Apache'nin yaptığı gibi parlamaz. 

 

Kinsta hosting architecture.

Kinsta barındırma mimarisi. 

  

Öte yandan, dediğimiz gibi, dizin seviyesinde konfigürasyonlara izin vermeyerek, Nginx, Apache'ye göre önemli bir avantaj elde eder. Nginx wiki'de performans etkisini karşılaştıran bir makale var: 

 

Performance impact Nginx vs Apache.png

Performans etkisi Nginx ve Apache.png 

 

  

Nginx Modülleri 

Nginx modül sistemi, onu daha premium bir seçenek olarak konumlandıran bir şey daha. Nginx modüllerinin tipik olarak derleme sırasında etkinleştirilmesi gerekir, bu da daha teknik bir hüner olduğu anlamına gelir ve modüllerin kurulum sonrası eklenmesi biraz daha karmaşıktır. 

  

2016'da 1.9.11 sürümüyle işler değişti ve resmi / doğrulanmış dinamik modüller deposu ödeme yapan kullanıcılara ayrıldı. Mayıs 2019 itibarıyla, QUIC ve HTTP / 3 için destek geliştirmeye başladıklarını duyurdular. 

 

 

Önbelleğe Alma Meselesi: Nginx ve Apache 

Önbelleğe alma - aşırı basitleştirmek istiyorsak - web sitesi ziyaretçileri için içeriği ziyaret etmeden önce hazırlamak olarak düşünülebilir, böylece "kapıyı çaldıklarında" aradıkları içeriği aramanıza gerek kalmaz. . Zaten hazırladınız ve beklemeden onlara veriyorsunuz. 

  

Apache gibi, Nginx’in tipik kurulumu, altyapının geri kalanında performans artışını hafifletmek için sunucular ve son kullanıcı arasında oturmaktı. Bu durumlarda, statik içeriği her seferinde korumalı, kaynak sunucudan getirmeye gerek kalmadan önbelleğe alabilir. 

  

Nginx'i bağımsız bir web sunucusu olarak kullanırsak - Kinsta LXC konteynerlerinde olduğu gibi - böyle bir ihtiyaç yoktur. Nginx, statik içeriği kendi başına sunmada çok etkilidir. 

  

Sonra dinamik önbellek veya sayfa önbelleği meselesi var. Bir WordPress web sitesinin senaryosunda bu, her URL için oluşturulan tüm WordPress sayfalarının bellekte veya diskte depolanması anlamına gelir. 

  

FastCGI önbelleğe alma, standart bir Nginx kurulumunda doğal olarak mevcuttur. Basit, çok güçlü ve daha az kullanılan Nginx özelliklerinden biridir. 

  

Bunu Apache karşılaştırmak için, Apache'nin diğer modüllerle çelişen, aksaklık eğiliminde olduğu bildirilen mod_cache modülüne sahip olduğunu bilmelisiniz. Dolayısıyla, Apache ile dağıtılan standart önbelleğe alma çözümü Varnish HTTP hızlandırıcısıdır. Varnish özel bir endüstri çözümü olmasına rağmen, son zamanlarda yapılan bazı testler, Nginx'in Vernik üzerinde net bir önbellek avantajı sağlıyor. 

  

Kinsta'da, dinamik WordPress önbelleği için Nginx'i, önbelleğe alınan sayfalar ve Kinsta CDN tarafından önbelleğe alınan statik varlıklar üzerinde ayrıntılı kontrol sağlayan tescilli bir önbelleğe alma eklentisi ile birlikte kullanıyoruz. 

  

Yavaş WordPress Barındırma hizmetinden bıktınız mı? Neredeyse anında ziyaretçilerinize içerik sunmak için sunucu düzeyinde tam sayfa önbelleğe alma kullanıyoruz.  

 

İşleme İstekleri: Nginx vs Apache 

Apache ve Nginx arasındaki en büyük fark, istekleri işleme yöntemlerinin temelindeki mimaridir. 

  

Apache, istekleri, "makinedeki ağ bağlantı noktalarına bağlanmaktan, istekleri kabul etmekten ve istekleri işlemek için  göndermekten sorumlu" olan MPM'ler veya Çoklu İşlem Modülleri ile işler. 

  

Apache’nin başlangıcına kadar uzanan en eski MPM, prefork modülüdür. Bu modül tek başına Apache’nin performansındaki kötü şöhreti nedeniyle kredilendirilebilir. Bu kipte, Apache her istek üzerine bir iş parçacığı ile yeni bir süreç oluşturur. 

  

Mod_php ile kullanılan bu modül, Apache sunucusunun, CSS dosyaları veya görüntüleri sunması gerekse bile, her bir işlemde bir PHP yorumlayıcısı yerleştirdiği anlamına geliyordu. 

  

Bu verimsizdi. Prefork modülü, varsayılan modül olarak Apache ile birlikte gelir. Ayrıca HTTP / 1 bağlantılarını da kısıtlar. 

  

Daha sonraki yıllarda, Apache çok iş parçacıklı işçi mpm'yi ve bundan sonra olay mpm'yi geliştirdi. Her ikisi de Apache’nin performans sorunlarının çoğunu hafifletir. Php-fpm'ye geçmek, Apache'nin .htaccess kullanımını ortadan kaldırmanın yanı sıra bugün hala rakip bir çözüm olmasını mümkün kılar, ancak bu, amacını bozar. 

 

Nginx, eşzamansız, engellemesiz olay güdümlü mimari kullanır. 

  

Farkı açıklamak gerekirse: Linux / Unix dünyasında, işlemler programları çalıştırır. 

  

İş parçacıkları, süreçlerin bir alt kümesidir ve bir işlem yürütme içinde birden çok iş parçacığı olabilir. Bunu bir tarayıcı penceresindeki birden çok sekme olarak düşünün. Bu şekilde bir program, daha hızlı yürütmek için birden çok CPU'yu ve çok çekirdekli, çok iş parçacıklı CPU'ları kullanabilir. Farklılıkları detaylandıran Linus Torvalds'ı okuyabilirsiniz. 

  

Kısacası, Apache her bağlantı için süreçler kullanır (ve işçi mpm ile evreleri kullanır). Trafik arttıkça, hızla çok pahalı hale gelir. 

  

Bir bilgisayarı başlatmak veya programları başlatmak gibi yeni süreci veya iş parçacığı oluşturmayı hayal edebiliriz. En hızlı bilgisayarlarda bile, biraz zaman alır. Günümüzde web siteleri tek bir sayfa yüklemesinde yüzlerce istekte bulunurken, bu hızla artıyor. 

  

Etkinlik mpm, optimizasyon açısından biraz daha ileri gider, ancak bazı testler Nginx'ten daha hızlı çalışamayacağını göstermektedir. Özellikle Nginx'in Apache'nin yaptığı isteklerin iki katı kadar hizmet verdiği statik dosyalardan bahsettiğimizde. 

  

Nginx'in ideal olarak CPU / çekirdek başına bir çalışan süreci vardır. Nginx çalışan süreçlerinin farkı, her birinin çalışan başına yüz binlerce gelen ağ bağlantısını idare edebilmesidir. Her bağlantı için yeni iş parçacığı veya süreç oluşturmaya gerek yoktur. 

 Cloudflare , MaxCDN gibi büyük İçerik Dağıtım Ağlarının ve ortağımız KeyCDN 'nin - veya Netflix gibi web sitelerinin - içerik sunumu için Nginx'i önemli bulmasının nedeni budur. 

  

Nginx'ten yararlanan şirketlerin listesi hepsini listelemek için çok uzun, bu yüzden WordPress.com'un arkasındaki özel şirket Automattic ile bitireceğiz. 

  

Automattic, 2008 yılında tüm yük dengeleyicilerini WordPress.com için Nginx'e dönüştürdü (buradan okuyabilirsiniz) ve sunucu yığınlarını tamamen Nginx'e taşıdı. 

 

 

Gerçek Hayatta Kontrol Etmek 

Üretimdeki web sitesinin ne kullandığını incelemek istersek, bunu genellikle HTTP yanıt başlıklarında bulabiliriz. Bu, geliştirici araçlarında bir web sitesi> İncele'ye sağ tıklamamız gerekeceği anlamına gelir, ağ panelini seçeceğiz ve ardından web sitesini yeniden yükleyeceğiz. Web sitesinin yüklediği tüm kaynakları göreceğiz. Herhangi bir belirli kaynağı ve Başlıklar sekmesini seçersek, genellikle sunucu bilgilerini göreceğiz. Web sitesi CDN kullanıyorsa, sunucu hattında Cloudflare gibi bir şey veya web sitesi HTTP hızlandırıcı kullanıyorsa Varnish gibi bir şey görebiliriz. 

  

Bu, cPanel, Apache ve PHP ile tipik bir paylaşılan barındırma kurulumu kullanan bir WordPress web sitesi örneğidir: 

 

Apache http header

Apache HTTP başlığı 

  

Bu, Nginx'te bir web sitesidir: 

 

Nginx http header

Nginx HTTP başlığı 

  

Sol tarafta, eğer onu genişletirsek, her kaynağın zamanını da analiz edebilir ve genel sayfa yükleme süresi üzerindeki etkisini görebiliriz. 

  

 

Özet 

Bu makalede, Nginx ve Apache'ye odaklandım ve Nginx'in web sunucusu alanında daha fazla ilgi kazanmasına yardımcı olan temel mimari farklılıkları açıkladım. Bunlar, kaynaklara aç sektörümüzde ona performans avantajı sağlayan temel özelliklerdir. 

  

Elbette, her kullanım durumu aynı önceliklere sahip değildir ve Apache veya LighttpdIISLiteSpeedCaddy gibi diğer araçlar iyi çözümler olabilir. 

  

Kinsta'da, WordPress ve WooCommerce için performansı optimize edilmiş barındırma çözümlerimizin bir parçası olarak Nginx kullanıyoruz. Her WordPress sitesi, onu çalıştırmak için gerekli tüm yazılım kaynaklarına (Nginx, Linux, PHP, MySQL) sahip kendi yalıtılmış konteynerinde barındırılır. Kaynaklar% 100 özeldir ve diğer siteler arasında paylaşılmaz. 

  

Bu makaleyi beğendiyseniz, UltaHost barındırma platformunu seveceksiniz. Destek ekibimizden 7/24 destek alın. Güçlü altyapımız otomatik ölçeklendirme, performans ve güvenliğe odaklanır. Size farkını gösterelim! Planlarımıza göz atın