LiteSpeed vs Apache vs Nginx: Hosting Performansı için Net Kıyas

Giriş: Hangi web sunucusu daha hızlı çalışır?

Hosting performansı sadece “hızlı server” gibi genel bir cümle değildir. Aynı sitenin farklı altyapılarda (LiteSpeed, Apache, Nginx) aldığı yanıt süreleri; cache davranışı, eşzamanlılık yönetimi, TLS/HTTP2 ayarları ve PHP-FPM entegrasyonuna göre değişir. Bu yazıda; üç sunucunun performans farklarını TTFB (first byte), CPU/mem kullanım paterni ve tipik hosting senaryoları üzerinden net şekilde ayıracaksınız.

Aşağıdaki bölümlerde, NetKıyas’ta karşılaştırma yaparken işinize yarayacak bir “seçim mantığı” oluşturacağız: Hangi durumda LiteSpeed öne çıkar, hangi durumda Nginx mimarisi daha avantajlı, hangi durumda Apache doğru tercih olur.

1) Temel mimari fark: Aynı site neden farklı hızlanır?

Web sunucusunun performansı; istek akışında nerede maliyet oluştuğuyla ilgilidir. HTTP isteği geldiğinde sırayla şu adımlar yürür: bağlantı kabulü (accept), istek çözümleme, statik içerik yanıtı, dinamik içerik için uygulama (PHP/Node) çağrısı, sonra yanıt üretme.

Bu noktada üç sunucu farklı yaklaşımlar sergiler:

Nginx: Event-driven yaklaşımıyla (non-blocking) yüksek eşzamanlılıkta güçlüdür. Statik içerik ve reverse proxy kullanımında çok sık tercih edilir. Dinamik içerikte PHP-FPM gibi arka servislerle çalışır.
Apache: Modüler mimarisi vardır. PHP’yi mod_php ile çalıştırmak yerine güncel kurulumlarda genellikle event/worker modları ve PHP-FPM entegrasyonu ile daha dengeli performans yakalanır.
LiteSpeed: LiteSpeed’in mimarisi, Apache eklentileriyle uyumluluk hedefler ve özellikle cache katmanında (LSCache) pratik avantaj sunar. Birçok managed hosting paketinde “hazır performans” hissini bu yüzden verir.

Buradan çıkan net sonuç şudur: Sunucuyu seçmek, doğrudan “cache’in nerede ve nasıl çalışacağına” karar vermektir. Aynı PHP uygulaması ve aynı veritabanı, cache katmanının kurulumu değiştiğinde farklı hızlanır.

Neden “aynı RAM/CPU” yine de farklı hız verir?

Çünkü sunucular aynı donanım üzerinde aynı tür yükte farklı davranır. Örneğin: - Çok sayıda kısa istek (küçük resimler + API çağrıları) eşzamanlılığı zorlayabilir. - Uzun çalışan istekler (ağır sayfa üretimi, raporlar) worker kuyruğunu doldurabilir. - Yanıt boyutu büyükse (dosya indirmeleri) ağ ve TLS ayarları öne çıkar.

Bu yüzden seçim, “paket CPU’su” kadar şu parametrelerle de yapılmalıdır: - LSCache / proxy cache / reverse proxy var mı? - PHP-FPM ayarları (worker sayısı, max_children) nasıl? - HTTP/2, TLS 1.2/1.3 ve session resumption düzgün mü? - Rate limiting ve WAF entegrasyonu var mı?

2) Karşılaştırma metrikleri: Hosting performansında ne ölçmelisiniz?

Performans kıyası yaparken sadece “genel hız” demeyin. Şunları ölçün veya hizmet sağlayıcısının raporlarını isteyin:

En kritik 3 metrik

TTFB (First Byte): Sunucu ilk yanıtı ne kadar hızlı döndürüyor?
P95/P99 gecikme: Ortalama hız değil, kuyrukta yaşanan yavaşlamalar. E-ticarette özellikle önemlidir.
CPU/mem dalgalanması: Zirvede sistem stabil mi, yoksa swap’a kayıyor mu?

Ek olarak: - Kabul edilen bağlantı sayısı ve bağlantı başına kullanım - Keep-Alive ve HTTP/2 multiplexing davranışı - Cache hit oranı (sayfa + nesne cache)

3) Net senaryolar: Hangi sunucu hangi yükte daha avantajlı?

Aşağıdaki tablo, pratik seçim yapmanız için tasarlandı. “Hangi sunucu her zaman hızlıdır?” yok; ama “hangi yükte daha sık öne çıkar?” var.

Senaryo	Beklenen darboğaz	Daha sık avantajlı	Net neden
Çok sayıda ziyaretçi, kısa sayfalar, yüksek concurrency	Eşzamanlılık ve event loop	Nginx	Event-driven yapı ve reverse proxy uyumu
Çok sayıda sayfa + statik içerik + uygulama cache ihtiyacı	Cache katmanı ve yanıt üretim maliyeti	LiteSpeed	Sunucu seviyesinde cache seçenekleri (LSCache) ile hızlı yanıt
Karma modüler Apache eklenti bağımlılığı olan ortamlar	Uyumluluk + mod yönetimi	Apache	Mevcut eklenti/konfig mirasını taşımak kolay
API ağırlıklı, reverse proxy + rate limit + WAF	Proxy performansı	Nginx	Reverse proxy ve sınırlandırma kabiliyeti
Paylaşımlı hostingte “paket hazır hız” beklentisi	Sunucu ayarlarının erişilebilirliği	LiteSpeed (genellikle)	Managed ortamda cache ve konfig kontrolü daha pratik

LiteSpeed hangi şartlarda net öne geçer?

Uygulama sayfalarında dinamik üretim (PHP) ve aynı sayfanın tekrar tekrar çalışması varsa
Cache’in sunucu katmanında etkinleştirilmesi mümkünse
Aynı anda yüksek sayıda ziyaretçi geliyorsa ve managed ortam ölçülebilir şekilde stabil çalışıyorsa

Net kontrol soruları: - “Cache açılı mı? (sayfa cache + nesne/operation cache)” - “LSCache için TTL ve purge (temizleme) nasıl yönetiliyor?” - “CDN ile çakışma nasıl ayarlanıyor?”

Nginx hangi şartlarda net daha doğru seçim olur?

Reverse proxy mimarisiyle çok servisli yapı kuruluyorsa (ör. Nginx -> uygulama servisleri)
Yüksek eşzamanlılıkta kuyruk ve kaynak tüketimi optimize edilmek isteniyorsa
API trafiği, dosya indirme, websocket/stream gibi akışlar varsa

Net kontrol soruları: - “HTTP/2 multiplexing etkin mi?” - “PHP-FPM socket mi TCP mi kullanıyor? Keep-Alive ayarı nedir?” - “Worker bağlantı limitleri (worker_connections vb.) pratikte nasıl ölçekleniyor?”

Apache hangi şartlarda net korunur?

Mevcut sistemde Apache modülleri, kural setleri ve .htaccess bağımlılığı belirginse
Organizasyonel süreçte Apache tabanlı dokümantasyon/konfig standartsa
Yönetilen hostingte Apache “boş ayarlar” ile değil, düzgün tuning ile çalışıyorsa

Net kontrol soruları: - “PHP mod_php kullanılıyor mu, yoksa PHP-FPM mi?” - “Güncel worker/event ayarları var mı?” - “Yük altında request queue davranışı nasıl?”

4) PHP tarafı: Sunucu seçiminden daha sık performansı belirleyen gerçek

Birçok hosting performansı kıyasında yanlış varsayım şudur: “Web sunucusu neyse hız odur.” Oysa modern kurulumlarda asıl yük PHP-FPM worker’ları, bağlantı havuzu ve veritabanı sorgularıdır.

PHP-FPM worker ayarı (net etkisi)

Web sunucusu hızlı yanıt üretse bile PHP-FPM kuyrukta kalıyorsa TTFB yükselir.
Worker sayısı düşükse istekler sıraya girer.
Worker sayısı yüksekse CPU/mem artar, cache hit oranı düşebilir ve gecikmeler uzar.

Bu yüzden karşılaştırma yaparken sadece sunucuyu değil şu cümleyi netleştirin: - “PHP-FPM’de kullanılan max children / start servers ayarı nedir?” - “Rate limit veya autoscaling var mı?”

Veritabanı bağlantısı: “Too many connections” performansı bozar

Veritabanı bağlantı limiti dolduğunda web sunucusu rolünü kaybeder; cevap süreleri uzar ve hata oranı artar. Bu tipte sorun yaşayan sitelerde web sunucu seçimi ikincil kalır.

Net kontrol: - Uygulama connection pooling yapıyor mu? - MySQL/PostgreSQL bağlantı limitleri dengeli mi?

5) Hosting planı seçerken sunucu farkını nasıl “ölçülebilir” karara çevirirsiniz?

NetKıyas tarzı karşılaştırmada ana hedef, “kulağa iyi gelen” paketi değil, sizin kullanım profiliniz için ölçülebilir sonucu almak.

5.1. Kendi profilinizi 4 soruyla sınıflandırın

Aşağıdaki sorulara net cevap verin: 1. Trafik piklerinde eşzamanlı kullanıcı sayısı artıyor mu? 2. Sayfalar ağır mı (çok görsel, slider, büyük template) yoksa hafif mi? 3. Dinamik içerik yoğun mu (çok sayfa PHP çalıştırıyor mu)? 4. Cache/Redis gibi katmanlar kullanıyor musunuz?

Sonuç eşlemesi (pratik): - Eşzamanlılık + statik ağırlık: Nginx çoğu zaman daha tutarlı olur. - Sayfa üretimi + sunucu cache ile ivme beklentisi: LiteSpeed daha sık avantaj sağlar. - Modül mirası + mevcut Apache ekosistemi: Apache mantıklı kalır.

5.2. Sunucu dışında “performansı bozan” 6 yaygın hata

Şunlar, web sunucu farkını gölgeler: - Sunucuda CPU/mem limitlerine yakın planlama (pik anında swap) - Cache açık olsa bile yanlış TTL/purge stratejisi - HTTP/2 ve TLS ayarları zayıf (özellikle mobil ağlarda) - PHP-FPM worker ayarları trafikle uyumsuz - CDN kullanılmasına rağmen origin cache kontrolü yanlış - Veritabanında yavaş sorgular (arama/rapor ekranları)

Bu hataları yönetmeden sunucuyu değiştirmek, beklenen farkı getirmez.

5.3. Aynı test senaryosunu 3 sunucuda karşılaştırma (net yöntem)

Mümkünse aynı uygulamayı ve aynı cache politikasını koruyun: - Test edilecek URL sayısı: 10-20 adet - Ölçüm: TTFB + P95 gecikme - Test aracı: HTTP istekleri ve tarayıcı benzeri yük (kurumsal ortamda kademeli) - Aynı saat aralığında deneme: trafik etkisini azaltın

Net hedef: Ortalama yerine P95 ve hata oranına bakın. Örneğin bir sunucu ortalamada 100ms, P95’te 800ms ise e-ticaret akışında “indirim günü çökmesi” gibi etkiler doğurur.

Sonuç: Hız hedefiniz için net seçim yapın

LiteSpeed, Apache ve Nginx’in performansını belirleyen şey “sunucunun adı” değil; cache stratejisi, PHP-FPM dengesi ve eşzamanlılık yönetimidir. Genel kural olarak: statik ağırlık ve reverse proxy odaklı mimarilerde Nginx, sunucu seviyesinde cache ile pratik hız beklentisinde LiteSpeed, mevcut modül/uyumluluk mirası baskınsa Apache daha net bir başlangıç noktasıdır.

Aksiyon önerisi: Hosting paketi seçmeden önce sağlayıcıdan cache’in nasıl çalıştığını, PHP-FPM ayarlarının temel değerlerini ve HTTP/2/TLS durumunu yazılı isteyin; ardından kendi URL setinizle TTFB ve P95 üzerinden küçük bir karşılaştırma testi yapın. Bu yaklaşım, doğru sunucuyu “tahmin” değil “ölçüm” ile seçmenizi sağlar.