LiteSpeed mi Apache mi? Fark gerçekte nerede açılır

Her LiteSpeed tanıtımında aynı grafik dolaşır: soldaki çubuk Apache, sağdaki LiteSpeed, arada 8-10 kat fark. O grafiğin söylemediği şey şu — soldaki Apache'de hiçbir sayfa cache'i yok, sağdaki LiteSpeed'de LSCache açık. Ölçülen şey iki web sunucusu değil, cache'li site ile cache'siz site.

Gerçek soru daha dar ve daha can sıkıcı: senin trafiğinde, senin uygulamanda ne kazanıyorsun ve bu kazanç lisans bedeline değiyor mu? Aşağıda bunu ölçülebilir hale getirmeye çalışıyorum.

İki mimari, tek cümlede fark

Apache'de eşzamanlılığı MPM belirler. prefork + mod_php kurulumunda her bağlantı bir işletim sistemi süreci demektir; mod_php yüklü bir süreç tipik olarak onlarca MB bellek tutar. Paylaşılan sayfalar düşüldüğünde gerçek maliyet daha azdır ama süreç sayısıyla birlikte doğrusal büyür. 500 eşzamanlı bağlantı bu modelde önce bellek problemidir, sonra hız problemi. mpm_event + PHP-FPM ise bağlantıları thread havuzuyla karşılar, keepalive bekleyen bağlantıları dinleyici tarafına geri devreder ve tamamen başka bir sunucu gibi davranır.

Önce kendi tarafına bak:

• httpd -V | grep -i mpm — hangi MPM'de olduğunu söyler; Debian/Ubuntu'da komut apache2ctl -V
• httpd -M — yüklü modüllerin listesi; geçiş kararının yarısı burada

LiteSpeed Enterprise olay güdümlüdür: az sayıda işçi süreci çalışır, binlerce açık bağlantı bu süreçlerde toplanır. PHP'yi FastCGI yerine LSAPI ile konuşur. Apache'nin httpd.conf'unu ve .htaccess'i doğrudan okuduğu için cPanel sunucusunda onun yerine geçebilen bir alternatiftir, ayrı bir dünya değil.

Burada dürüst olalım: eğer Apache kurulumun hâlâ prefork + mod_php ise, yaptığın karşılaştırma LiteSpeed'e karşı değil, kendi konfigürasyonuna karşıdır. Önce mpm_event + PHP-FPM'e geç, sonra tekrar ölç. "Apache yavaş" vakalarının önemli bir kısmı buradan çıkıyor.

LSCache gerçekte ne yapıyor

LSCache'in tamamı tek bir cümlede: cache, web sunucusunun içinde. Bir istek cache'e isabet ettiğinde PHP hiç başlamaz, MySQL'e hiç gidilmez, sitenin onlarca eklentisi hiç yüklenmez. Cevap diskteki cache dosyasından okunur; sıcak dosyalar zaten çekirdeğin sayfa önbelleğinde, yani pratikte RAM'den servis edilir.

Kendiliğinden açılmaz: sunucu yapılandırmasında bir cache kökü tanımlı olmalı (CacheRoot), uygulama tarafında da cevabı cache'lenebilir diye işaretleyen bir taraf bulunmalı. WordPress'te bu işi LiteSpeed Cache eklentisi yapar; eklenti kurulu değilse sunucu dinamik cevapları kendi kararıyla saklamaz.

Uygulama cache'i cevap başlıklarıyla yönetir:

• X-LiteSpeed-Cache-Control: public,max-age=3600 — bu cevabı public cache'e al
• X-LiteSpeed-Tag: post,123 — cache girdisini etiketle
• X-LiteSpeed-Purge: post,123 — sadece o etikete sahip girdileri düşür

Etiket temelli purge, tam sayfa cache'i elle kuran herkesin en çok özlediği şey. Bir yazı güncellendiğinde tüm siteyi uçurmak yerine yazının kendisi, kategori sayfası ve ana sayfa düşer; geri kalan cache yerinde kalır.

Doğrulaması tek satır:

curl -sI https://ornek.com/ | grep -i x-litespeed-cache

x-litespeed-cache: hit görüyorsan iş bitmiştir. Sürekli miss geliyorsa ya bir çerez cache varyasyonu üretiyordur ya da bir eklenti her cevaba no-cache başlığı basıyordur. Bu ikisi, geçiş sonrası "hiçbir şey değişmedi" şikayetlerinin çoğunu açıklar.

ESI ile sepet tutarı, oturum kutusu gibi kişiye özel parçalar sayfada delik olarak bırakılır; sayfanın kalanı public cache'ten gelir. Aynı şeyi Apache tarafında eklenti cache'iyle kurmak mümkündür ama belirgin biçimde daha kırılgandır.

Ama şu da doğru: LSCache'in verdiği kazancın büyük kısmını Apache'de de alabilirsin. İyi bir full-page cache eklentisi ya da önde Varnish, aynı isteği PHP'ye sokmadan karşılar. Fark, LSCache'te bunun kurulum işi olmaktan çıkıp sunucunun standart davranışına dönüşmesi. Adil kıyas "Apache + cache eklentisi" ile "LiteSpeed + LSCache" arasındadır ve o kıyasta fark 8-10 kat değildir; düşük eşzamanlılıkta neredeyse yoktur, yük arttıkça açılır.

.htaccess: ne taşınır, ne sessizce bozulur

LSWS Enterprise .htaccess'i Apache söz dizimiyle okur. Kullanıcıların yazdığı rewrite kurallarına dokunmadan geçebilirsin. İki teknik ayrıntı önemli:

• Apache, AllowOverride kapalı değilse her istekte dizin ağacında .htaccess arar; bu, istek başına birden fazla dosya sistemi çağrısı demektir. LiteSpeed ayrıştırdığı .htaccess'i bellekte tutar ve dosyanın değişiklik zamanı değişince yeniden okur. Derin dizinli, .htaccess'i bol kurulumlarda bu tek başına ölçülebilir bir kazançtır.
• Apache'nin .so modülleri yüklenmez. Rewrite ve ModSecurity kural söz dizimi sunucunun kendi içinde karşılanır; ama mod_wsgi, mod_perl, mod_pagespeed gibi modüllerin karşılığı yoktur. httpd -M çıktısında tanımadığın bir modül varsa, geçişten önce onun ne yaptığını çöz.

En sinsi tuzak bu değil. Şu:

<IfModule mod_php7.c> bloğu, mod_php yüklü olmayan hiçbir kurulumda eşleşmez — LiteSpeed altında da, PHP-FPM'e geçmiş bir Apache'de de. İçindeki php_value memory_limit 512M satırı sessizce yok sayılır. Hata mesajı yok, log satırı yok; limit eski değerinde kalır ve iki hafta sonra bir müşteri "beyaz ekran" diye yazar. Güvenlik ve performans eklentileri PHP ayarlarını tam olarak bu blokların içine yazar. Geçişten sonra kritik hesaplarda bir phpinfo() ile fiilî değerleri doğrula; PHP limitlerini bloğun dışına ya da hesabın kendi PHP ayarlarına taşı.

OpenLiteSpeed ayrı bir konu: ücretsizdir ama .htaccess desteği tam değildir (pratikte rewrite kurallarıyla sınırlıdır) ve cPanel'in desteklediği bir web sunucusu değildir. Tek uygulamalı bir VPS için makul bir seçim; kullanıcıların kendi .htaccess'ini yazdığı paylaşımlı bir sunucu için değil.

Lisans, kapasite planının bir girdisidir

Apache'nin lisansı yok, LiteSpeed'in var. Kademeler sunucunun kaynaklarına göre ayrılır: alt kademelerde bellek tavanı, üst kademelerde CPU ve işçi süreci tarafında sınır. Kademe tablosu zaman içinde değişir, o yüzden rakamı satın alma anında doğrula. Değişmeyen kısım şu: lisans, kapasite planının bir girdisidir ve sonuçları teknik değil, operasyoneldir.

• Sunucu büyütmek iki adımlı bir iş: önce lisans kademesi, sonra donanım. Ters sırada yaparsan makineyi lisansın karşılamadığı bir konfigürasyonda çalıştırmaya kalkarsın.
• Sanal sunucuda lisansın gördüğü şey, misafir işletim sisteminin raporladığı kaynaktır. nproc ve free -g çıktısı ne diyorsa plan onun üzerine kurulur; "aslında paylaşımlı çekirdek" argümanının bir karşılığı yoktur.
• Yoğunluk stratejin maliyeti değiştirir. 200 hesabı tek büyük makineye yığmakla iki küçük makineye bölmek aynı tabloyu üretmez; ikinci seçenekte iki ayrı lisans ödersin. Kararı ölçeklendirmeden önce ver.
• Maliyeti hesap başına düşün, sunucu başına değil. 300 WordPress hesabı barındıran bir makinede lisans, hesap başına ihmal edilebilir bir kalemdir; tek bir kurumsal siteyi taşıyan güçlü bir makinede aynı rakam ciddi bir gider satırıdır.

vialicense'ta LiteSpeed lisansı sunucunun IP adresine bağlanır, anahtar dosyasına değil. Makineyi taşıdığında IP'yi panelden kendin değiştirirsin ve eski adres o anda durur — donanım değişikliği bir destek talebi konusu olmaktan çıkar.

Fark hangi yükte açılır

• Statik dosya, düşük eşzamanlılık: fark yok denecek kadar az. mpm_event zaten hattı doldurur. Buraya bakarak karar verme.
• Cache'lenebilir dinamik trafik (haber sitesi, blog, ürün listeleme): en büyük fark burada. LSCache isabetinde istek PHP'ye hiç girmediği için sunucunun harcadığı süre milisaniyeler bandına iner; kullanıcının gördüğü sürenin geri kalanı ağ gecikmesidir.
• Cache'lenemeyen dinamik trafik (oturum açmış kullanıcı, panel, forum): LSAPI ile PHP-FPM arasındaki fark ölçülebilir ama küçüktür. Burada darboğaz neredeyse her zaman veritabanıdır ve web sunucusunu değiştirmek sorunu çözmez.
• Yüksek eşzamanlılık, çok sayıda açık bağlantı: mimari farkını asıl burada görürsün. Binlerce keepalive bağlantısı Apache'de süreç ya da thread tüketir, LiteSpeed'de birkaç işçi sürecinde birikir.
• HTTP/3 ve TLS yoğun trafik: LiteSpeed HTTP/3'ü sunucunun kendi içinde konuşur. Apache'nin kararlı sürümlerinde HTTP/3 hâlâ yok; istiyorsan önüne ayrı bir katman koyman gerekir.
• Flood ve kötü bot: IP başına bağlantı ve bant genişliği limitleri sunucunun kendi ayarlarında tanımlıdır. Apache'de aynı şeyi ek modüller ya da güvenlik duvarı katmanıyla kurarsın.

Ölçmenin dürüst yolu:

curl -o /dev/null -s -w 'ttfb=%{time_starttransfer} total=%{time_total}\n' https://ornek.com/

Sonra yük altında wrk -t4 -c200 -d30s https://ornek.com/. Ama ana sayfaya birkaç istek atıp "10 kat" demek ölçüm değil, reklamdır. İki tarafı da aynı cache stratejisiyle ve aynı sayfalarla test et; yoksa cache'i ölçmüş olursun, sunucuyu değil.

Ne zaman geçmeye değmez

• Günde birkaç bin isteği olan tek bir site. Darboğazın web sunucusu değil; tema, sorgu sayısı ya da bir eklenti.
• Önünde tam sayfa cache yapan bir CDN varsa. İstek origin'e zaten gelmiyorsa origin'in ne olduğu büyük ölçüde önemsizdir.
• Node, Java ya da Python uygulaması ters vekil arkasındaysa. LSCache PHP dünyasında parlar; ters vekil rolünde kazanç sınırlıdır.
• Her sayfası kişiye özel bir SaaS paneli. Private cache ve ESI var ama ciddi bir uyarlama işi; aynı emeği opcache ve Redis object cache'e verirsen Apache'de benzer sonucu alırsın.
• Ekipte LiteSpeed bilen kimse yoksa ve sunucuyu gece üçte ayağa kaldıracak kişi Apache biliyorsa. Teknik olmayan ama gerçek bir kriter.

Basit kural: web sunucusu süreçleri CPU'nun %20'sinden azını yiyorsa, sorun web sunucusu değildir.

Geçeceksen geri dönüş yolunu açık tut

cPanel'de LiteSpeed Apache'yi silmez; yanına kurulur ve portları devralır. Kurulumla birlikte gelen iki komut kararı geri alınabilir kılar:

• /usr/local/lsws/admin/misc/cp_switch_ws.sh lsws
• /usr/local/lsws/admin/misc/cp_switch_ws.sh apache

Geri dönüş saniyeler sürer. Denemeyi düşük riskli yapan asıl şey performans vaadi değil, bu.

Geçiş sonrası kontrol listesi:

• curl -sI https://ornek.com/ | grep -i '^server' çıktısı Server: LiteSpeed mi
• /usr/local/lsws/logs/error.log ve stderr.log: lsphp çökmeleri buraya düşer
• <IfModule mod_php...> bloklarına gömülmüş PHP ayarları
• Cron ve CLI tarafında kullanılan PHP sürümü değişmiş mi
• ModSecurity kural setin yükleniyor mu

Karar

Paylaşımlı hosting, yüzlerce WordPress hesabı ve CloudLinux ile LVE sınırlaması yapıyorsan geç; en net kazanç orada, hem yanıt süresinde hem bellek tüketiminde. Tek bir kurumsal site ama ağır ve cache'lenebilir trafik varsa bir ay dene ve ölç. Küçük site ya da uygulama sunucusuysa Apache yeterli; parayı RAM'e ve veritabanına harca.

Denemeye karar verirsen LiteSpeed lisansı ön ödemeli bakiyeden otomatik düşer, onay adımı yoktur ve genellikle bir dakika içinde çalışır; kurulum sunucuda tek komuttur, betik lisansı IP'den bulur. Aylık lisans dönem sonuna kadar çalışır, taahhüt ve cayma bedeli yok — yani bir ay ölçmek, tahmin yürütmekten ucuza gelir. Aynı bakiyeden yönetilen diğer kalemleri sunucu performans lisansları sayfasında görebilirsin.