Paylaşımlı Hostingde JekCMS: 14 Canlı Siteden Gerçekçi Performans Rehberi

Bu yazıdaki her şey kendi hosting hesabımdan geliyor. Geliştirdiğim CMS olan jekcms üzerinde 14 içerik sitesi işletiyorum ve hepsi paylaşımlı hostingde çalışıyor: LiteSpeed sunucular, önde Cloudflare. En büyük sitede 2.300'den fazla yayınlanmış yazı var; filonun toplamı 5.500'ü geçti. Arkada saklanan bir VPS yok. Yani "paylaşımlı hosting ciddi bir içerik sitesine yeter" derken bir yerlerde okuduğum benchmark'ı tekrarlamıyorum; trafiğimin gerçekten indiği makineleri anlatıyorum.

Aynı zamanda bir deploy'un ortasında kendi hostumdan IP banı yediğim yer de orası. Paylaşımlı hosting gayet iyidir — ama ona VPS muamelesi yaparsanız cezalandırır. Bu rehberin konusu tam olarak o fark.

Config değerlerinden önce beklentileri ayarlayın

Paylaşımlı planda satın aldığınız şey şu: açgözlülük ettiğiniz anda kısılan bir CPU dilimi, yabancılarla paylaştığınız disk IO'su, ayarlarına dokunamadığınız bir MySQL sunucusu ve root yok. Genellikle Apache yerine LiteSpeed — bu iyi haber, çünkü hızlı ve .htaccess dosyanızı zaten okuyor.

Bundan iki kural çıkıyor; aşağıdaki her bölüm aslında bu ikisinden birinin kılık değiştirmiş hâli:

• İsteklerin çoğu PHP'ye hiç ulaşmamalı.
• PHP çalıştığında olabildiğince az iş yapmalı.

Önbellek katmanları paylaşımlı hostingde nasıl diziliyor?

jekcms'te sayfa, veri ve sorgu önbellekleri var; ama paylaşımlı hostingde işin neredeyse tamamını biri yapar: sayfa önbelleği. Bir URL'ye gelen ilk istek HTML'in tamamını üretir ve diske yazar. TTL dolana kadar (varsayılan 300 saniye) sonraki her istek o dosyadan servis edilir. Yönlendirme yok, sorgu yok, şablon üretimi yok.

TTL'i neden bir saate çıkarmadığımı soranlar oluyor. Çıkarabilirim. Ama beş dakika bile, insanların gerçekten ziyaret ettiği sayfalarda pahalı üretimin nadiren koşması demek — üstelik zamanlanmış yazılar ve düzenlemeler, purge derdi olmadan kısa sürede görünüyor. Dokunmak için bir neden bulamadım.

Sayfa önbelleğinin üstünde Cloudflare oturuyor; görselleri, CSS ve JS'i sunucumdan tamamen alıyor. Altında ise OPcache var — sanıldığından daha önemli, çünkü bir sayfa önbelleği isabeti bile sonuçta dosya okuyan bir PHP'dir. Ve paylaşımlı hostingde beni en çok ısıran yer OPcache oldu.

HTML'i Cloudflare'e neden emanet etmiyorum?

Cazip fikir: Cloudflare'e bir "cache everything" kuralı koyup tam sayfaları da edge'den servis ettirmek. Başlarda denedim ve geri adım attım. Edge HTML'inizi tutmaya başladığı anda her yayın, her düzenleme, her yorum onayı Cloudflare'e de bir purge çağrısı gerektiriyor — ve birini unuttuğunuzda (unutacaksınız), bayat sayfa saatlerce edge'de yaşıyor ve sunucunuzdaki hiçbir şey bunu düzeltemiyor. Statik varlıklar ise tam tersi bir durum: içerikleri değişince URL'leri de değişiyor, dolayısıyla edge'de bir yıl risksizce oturabiliyorlar. Benim bölüşümüm bu yüzden sıkıcı ve bilinçli: varlıklar Cloudflare'in, HTML origin'deki sayfa önbelleğinin; en kötü bayatlık senaryom da beş dakikalık TTL. Paylaşımlı hostingde bu bölüşüm, purge koreografisine hiç girmeden kazancın çoğunu getiriyor.

Her deploy'dan sonraki OPcache tuzağı

Arıza şöyle işliyor: yeni PHP dosyalarını deploy ettiniz, disktekiler güncel. Ama OPcache hâlâ eski dosyaların derlenmiş baytkodunu servis ediyor ve opcache.revalidate_freq = 60 ile diske bakması bir dakikayı bulabiliyor — host doğrulama ayarlarını ezmişse daha da uzun. Bu arada dosyaların bir kısmı tazelenip bir kısmı tazelenmeyince site eski-yeni kod karışımı çalışıyor. "Düzelttiğim" bir hatanın production'da keyifle tekrar etmesini izlediğim oldu; düzeltme diskte vardı, OPcache'te yoktu.

Deploy hattım artık bunu pazarlık dışı sayıyor: rsync'ten sonraki son adım OPcache reset + sayfa önbelleği purge. İkisi koşmadan deploy bitmiş sayılmaz. Bu yazıdan tek bir alışkanlık alacaksanız, bunu alın.

Gerçek kullanımı yansıtan bir .user.ini

Çoğu paylaşımlı host, site köküne koyacağınız bir .user.ini dosyasıyla PHP ayarlarını ezmenize izin verir. Benimkiler zamanla şuna oturdu:

; .user.ini (site kökü)
max_execution_time = 90
memory_limit = 256M
upload_max_filesize = 32M
post_max_size = 48M
max_input_vars = 5000
opcache.memory_consumption = 128
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 10000
opcache.revalidate_freq = 60

Bariz olmayanların gerekçesi:

• max_execution_time = 90 — yönetim panelinin yaptığı en yavaş iş, büyük bir fotoğrafı AVIF ve WebP'ye çevirmek (jekcms yüklemede en fazla 1920px'e küçültüp iki formatı da üretiyor). Varsayılan 30 saniye tek görseli kurtarır; kısılmış bir CPU'da toplu yükleme bazen kurtaramaz.
• memory_limit = 256M — yine görsel dönüşümü. Yüksek çözünürlüklü bir fotoğrafı belleğe açmak, tüm CMS'in bellek zirvesidir.
• max_input_vars = 5000 — büyük admin formları çok sayıda alan gönderebilir; düşük bir limit gönderimi sessizce kırpar. Sessiz kırpılma, peşine düşülecek en kötü hata türüdür.
• opcache.memory_consumption = 128 — bazı paneller 64 veriyor; dolan OPcache dosyaları döne döne yeniden derliyor. Bu da deseni olmayan aralıklı yavaş sayfalar olarak karşınıza çıkıyor.

Tuhaflık 1: Hostunuz sizi deploy ettiğiniz için banlayabilir

En sevdiğim paylaşımlı hosting hikâyesi bu — çünkü içinde bozuk hiçbir şey yoktu ve yine de filonun yarısını yolda bıraktı.

Deploy'larım GitHub Actions'tan koşuyor: tek repo, 14 siteye tek tek rsync. Her rsync yeni bir SSH bağlantısı, yani yeni bir kimlik doğrulama açıyordu — aynı IP'den, saniyeler içinde, art arda on dört tane. Hostinger'ın saldırı korumasına göre bu birebir brute-force görüntüsü; runner'ın IP'sini döngünün ortasında banladı. Sitelerin yarısı yeni kodu aldı, yarısı almadı. Sekizinci siteden itibaren "connection refused" dışında hiçbir yerde hata yok.

Çözüm retry ya da sleep eklemek değil; SSH bağlantı çoklama:

# deploy isinin ~/.ssh/config dosyasinda
Host deploy-target
  HostName sunucu-adresiniz
  User kullaniciniz
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 5m

Tek kimlik doğrulama, tek soket; sonraki her rsync aynı bağlantının üzerinden gidiyor. Ban bir daha hiç tetiklenmedi. Paylaşımlı hosting deploy'unda vazgeçmediğim iki kural daha: rsync --delete olmadan çalışır ve .env, uploads/, cache/, logs/ hariç tutulur — sunucu tarafındaki durum, hattın yok etme yetkisinde değildir. GitHub'ın ya da SSH'ın huysuzlandığı gün içinse yedek yol hazır: sunucu tarafında cron ile git pull, aynı repoyu içeriden deploy eder.

Paylaşımlı hostingde cron bir piyango — kaybetmeye göre plan yapın

Paylaşımlı hosting cron'ları "gayet iyi" ile "minimum aralık 30 dakika, iş huysuzlanırsa sessizce kapatılır, ayarlar panelde üç menü derinde" arasında değişir. En kötü seviyeyi varsayın; çünkü zamanlanmış yayın, tam da bir yazı sessizce yayına girmeyene kadar bozulduğunu fark etmeyeceğiniz özelliktir.

jekcms bunu ziyaretçi tetiklemeli bir zamanlayıcıyla aşıyor. Gerçek bir cron algılanmadığında CMS "sıradaki iş" damgasına bakar ve vakti gelmiş ne varsa koşar — hem de yanıt ziyaretçiye teslim edildikten sonra; hiçbir istek onu beklemez. Olasılıksal değil deterministik: vakti gelen iş bir sonraki istekte koşar, nokta. Düşük trafikli bir sitede WP-Cron ile boğuştuysanız bu kelimeyi neden vurguladığımı biliyorsunuz. Gerçek bir cron kurduğunuzda ise yedek mekanizma bunu algılayıp kendini kapatır — çifte çalıştırma yok. İki modun ayrıntısı dokümantasyonun cron kurulumu bölümünde; zamanlayıcının iç işleyişini de ayrı bir yazıda anlattım.

Benim düzenim: panelin makul aralık verdiği yerde gerçek cron, geri kalan her yerde yedek mekanizma. Bunu düşünmeyi gerçekten bıraktım.

Peki veritabanı?

Beklediğinizden kısa bir bölüm; çünkü sayfa önbelleği onu kısaltıyor. Paylaşımlı hostingde MySQL'i ayarlayamazsınız — buffer pool boyutu yok, config erişimi yok — o yüzden hedef, ondan daha az şey istemek. Sayfa önbelleği açıkken ziyaretçi yolunda veritabanı çoğunlukla boşta oturur.

Edinmeye değer tek alışkanlık: hostunuz yavaş sorgu günlüğü sunuyorsa, büyük bir deploy ya da içerik aktarımından sonra bir günlüğüne açın. Orada ısrarla yavaş görünen şey neredeyse her zaman eksik bir indekse işaret eder ve ALTER TABLE ... ADD INDEX, paylaşımlı hostingin size bıraktığı az sayıdaki sunucu tarafı yetkiden biridir.

Paylaşımlı hostingin gerçekten bittiği yer

Dürüstlük bölümü. Tavan var; sadece "paylaşımlı hosting oyuncaktır" diyenlerin iddia ettiğinden daha uzakta. Benim planlarımda gerçekten acıtanlar: binlerce yazılık toplu aktarımlar, adanmış CPU'dakinden gözle görülür yavaş koşuyor (bitiyorlar; sadece keyifli değil), trafik zirvesinde yoğun admin çalışması ziyaretçilerle aynı kısılmış kaynaklar için yarışıyor ve gürültücü komşuyu asla düzeltemiyorsunuz — bazı öğleden sonraları aynı site düpedüz daha yavaş oluyor ve tek dürüst açıklama, başkasının WordPress'inin saldırı altında olması.

Beni paylaşımlı hostingden çıkarmayan şeyse şu: tek sitede 2.300'den fazla, filoda 5.500'den fazla yazı. Önbelleğe alınmış HTML, arkasında kaç satır olduğunu umursamaz. Garantili CPU'ya ya da kendi MySQL config'ime ihtiyaç duyduğum gün taşınırım — VPS yapılandırma referansı tam o gün için yazıldı. O gün henüz gelmedi; sunabileceğim en dürüst performans ölçütü de bu.