Bu kapsamlı rehberde; Keyhel Panel’de Jailed SSH ortamında güvenlikten ödün vermeden, gerekli izinleri ayarlamayı, NVM (Node Version Manager) kullanarak Node.js kurmayı ve uygulamalarınızı PM2 ile 7/24 kesintisiz nasıl çalıştıracağınızı adım adım anlatıyoruz.

1. Adım: Ön Hazırlık – “Ek İkili Dosyalar” ve Kütüphane İzinleri

Jailed SSH (Hapishane) ortamı, kullanıcıyı sadece belli başlı komutlarla sınırlandırır. NPM’in paketleri indirebilmesi, zipli dosyaları açabilmesi ve özellikle Vite/Rollup gibi modern araçların Linux çekirdek kütüphanelerine ulaşıp derleme (build) yapabilmesi için sunucu panelinizden bazı komutlara izin vermeniz gerekir.

Hosting panelinizden (Örn: KeyHelp’te Yapılandırma > Sınırlandırılmış SSH > Ek İkili Dosyalar bölümüne) aşağıdaki listeyi eksiksiz olarak ekleyin ve kaydedin:

/usr/bin/node
/usr/bin/npm
/usr/local/bin/pm2
/usr/bin/sed
/usr/bin/awk
/usr/bin/tr
/usr/bin/uname
/usr/bin/tar
/usr/bin/gzip
/usr/bin/xz
/usr/bin/sort
/usr/bin/grep
/usr/bin/tail
/usr/bin/head
/usr/bin/cut
/usr/bin/wc
/usr/bin/dirname
/usr/bin/find
/usr/bin/tee
/usr/bin/sha256sum
/usr/bin/rm
/usr/bin/cp
/usr/bin/mv
/lib/x86_64-linux-gnu/librt.so.1
/usr/lib/x86_64-linux-gnu/librt.so.1
/lib64/librt.so.1

Not: Listenin sonundaki librt.so.1 yolları, Vite ve Rollup kullanan projelerde derleme sırasında alınan Error: librt.so.1: cannot open shared object file (ERR_DLOPEN_FAILED) hatasının kesin çözümüdür.

2. Neden Jailed SSH’ta Standart Node.js Kurulumu Çöker?

İzinleri verdikten sonra bile, sistem sizi genellikle /www veya /home/kullaniciadi gibi bir dizine hapseder. Ancak Node.js ve NPM, kurulum ve önbellek (cache) işlemleri için ana sunucu dizinlerine (/.npm) erişmeye çalışır.

Bu durum karşılaştığımız en meşhur hatayı doğurur: Error: EACCES: permission denied, mkdir '/.npm'

Çözüm: Uygulamaları “Root” düzeyinde değil, tamamen kullanıcının kendi izole alanında (Kapsayıcı mantığıyla) kurmaktır.

3. Adım Adım NVM ile Özel Node.js Motoru Kurmak

Her müşteriye veya projeye kendi bağımsız Node.js motorunu atamak için NVM kullanıyoruz. Bu sayede aynı sunucuda bir proje Node 18 ile çalışırken diğeri Node 20 ile çakışmadan çalışabilir.

Terminalinize giriş yapın ve ortamı uyandırmak için şu komutları sırasıyla girin (NVM kurulu değilse standart cURL komutuyla kurabilirsiniz):

# NVM'in yolunu belirleyin
export NVM_DIR="/www/.nvm"

# NVM'i aktif edin
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

# İstediğiniz Node sürümünü kurun ve kullanın (Örn: v20)
nvm install 20
nvm use 20

4. NPM EACCES (Yetki) Hatalarını Tamamen Aşmak

NPM’in sunucu kök dizinlerine dosya yazmaya çalışmasını engellemek için ona “Ev” dizininin neresi olduğunu söylemeliyiz. Aşağıdaki komut, NPM’in tüm önbellek dosyalarını kısıtlı alanımız olan /www içerisine yazmasını sağlar:

export HOME="/www"

Sürüm Çakışmalarını (ERESOLVE) Gidermek

Projelerinizde paket sürümleri uyuşmazlığı (npm error ERESOLVE) yaşıyorsanız, NPM’e eski tip bağımlılık çözümlemeyi kullanmasını söyleyerek kurulumu zorlayabilirsiniz:

npm install --legacy-peer-deps

5. Jailed Ortamda PM2 Kurulumu ve “module_conf.json” Hatası Çözümü

Uygulamanızı arka planda sürekli çalıştıracak olan PM2’yi kurmak, yetki sorunlarının en çok yaşandığı yerdir. PM2 logları ve PID dosyalarını ana dizindeki /.pm2 içine yazmaya çalışır. Bunu önlemek için PM2’nin çalışma alanını yeniden yönlendiriyoruz:

# PM2'ye yeni bir ev gösteriyoruz
export PM2_HOME="/www/.pm2"

# PM2'yi global olarak kuruyoruz
npm install -g pm2

Kurulumun başarılı olup olmadığını test etmek için:

pm2 status

Bu komut size boş da olsa o meşhur PM2 tablosunu vermelidir.

6. Uygulamayı Başlatmak ve PM2’yi Kalıcı Hale Getirmek

Tüm altyapımız hazır. Şimdi Node.js veya derlenmiş (build edilmiş) projemizi canlıya alalım.

1. Uygulamanızın klasörüne girin:

cd /www/

2. PM2 ile uygulamayı başlatın: Birden fazla uygulama barındırıyorsanız --name parametresi ile isimleri birbirinden ayırmayı unutmayın.

pm2 start index.js --name "proje-adi" --cwd /www/

3. İşlemi Kaydedin: Sunucu herhangi bir sebeple yeniden başlatıldığında uygulamanızın otomatik olarak tekrar açılması için listeyi kaydedin:

pm2 save

Bonus: SSH Her Açıldığında Ayarları Korumak (.bashrc Otomasyonu)

Jailed SSH ortamları çok “unutkandır”. Terminali kapatıp açtığınızda pm2 status veya npm komutları tekrar hata verebilir. Çünkü girdiğimiz export komutları hafızadan silinir.

Her girişinizde tek bir kelimeyle ortamı hazırlamak için kendinize bir kısayol (alias) oluşturun:

echo 'alias start="export HOME=/www && export PM2_HOME=/www/.pm2 && export NVM_DIR=/www/.nvm && [ -s \"\$NVM_DIR/nvm.sh\" ] && . \"\$NVM_DIR/nvm.sh\" && nvm use 20"' >> /www/.bashrc
source /www/.bashrc

Artık SSH’a her bağlandığınızda sadece start yazıp Enter’a basmanız yeterlidir. Tüm NVM ve PM2 yollarınız saniyeler içinde arka planda hazır hale gelecektir.

Özet

Kısıtlı SSH izinleri, modern web uygulamaları geliştirmek için bir engel değildir. Doğru yapılandırılmış NVM ortamları, çekirdek librt izinleri ve export yönlendirmeleri ile ana sunucuya hiçbir zarar vermeden (Root yetkisi kullanmadan) tamamen izole, güvenli ve yüksek performanslı Node.js barındırma altyapıları kurabilirsiniz. Başarılar dileriz!

Bir WooCommerce mağazası kurdunuz, en iyi temayı aldınız, resimleri optimize ettiniz ve en popüler önbellek (Cache) eklentisini kurdunuz. Sitenizin anasayfası saniyeler içinde açılıyor. Ancak bir müşteri ürünü sepete eklediğinde veya ödeme sayfasına (Checkout) geçtiğinde sistem adeta kilitleniyor, saniyelerce yükleniyor ikonu dönüyor. Neden?

Çünkü statik sayfa önbellekleme (Page Caching), e-ticaret sitelerinde işe yaramaz.

Sepet, ödeme ve hesabım sayfaları her müşteri için benzersizdir (dinamiktir) ve önbelleğe alınamaz. Müşteri sepete tıkladığı an, sunucunuz veritabanına (MariaDB/MySQL) canlı bir sorgu atar. Eğer veritabanınız şişmişse ve sunucunuzun I/O (Okuma/Yazma) hızı yetersizse, o müşteri ödeme yapmaktan vazgeçip sitenizi terk eder.

SaviorHost mühendislik ekibi olarak, WooCommerce altyapısını yavaşlatan veritabanı krizlerini ve bu darboğazları sunucu seviyesinde nasıl aşacağınızı teknik detaylarıyla inceliyoruz.

1. Sessiz Katil: wp_options Tablosu ve Autoload Krizleri

WordPress mimarisinde temanızın, eklentilerinizin ve WordPress çekirdeğinin tüm ayarları wp_options tablosunda tutulur. Bu tablodaki en tehlikeli sütun ise autoload (otomatik yükle) sütunudur.

Eğer bir ayarın autoload değeri ‘yes’ ise, sitenizin herhangi bir sayfası yüklendiğinde WordPress bu veriyi veritabanından çeker. Kötü kodlanmış eklentiler (özellikle eski sayfa yapıcılar ve istatistik eklentileri) sildikten sonra bile verilerini burada bırakır. Zamanla bu tablo megabaytlarca şişer. Her sayfa açılışında sunucunuz boş yere 5-10 MB veriyi RAM’e kopyalamaya çalışır ve işlemciyi boğar.

Autoload Boyutunuzu Nasıl Ölçersiniz?

İdeal bir WordPress sitesinde autoload edilen veri boyutu 800 KB ile 1.5 MB arasında olmalıdır. Bunu kontrol etmek için phpMyAdmin’e girin, veritabanınızı seçin ve şu SQL sorgusunu çalıştırın:

SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_size_mb 
FROM wp_options 
WHERE autoload = 'yes';

Eğer sonuç 2 MB’ın üzerindeyse (bazı e-ticaret sitelerinde 15-20 MB’a kadar çıkar), siteniz her tıklamada veritabanı altında eziliyor demektir.

Suçluyu Bulmak ve Temizlemek

Hangi eklentinin veya temanın bu tabloyu şişirdiğini bulmak için şu sorguyu çalıştırın:

SELECT option_name, length(option_value) AS option_value_length 
FROM wp_options 
WHERE autoload='yes' 
ORDER BY option_value_length DESC LIMIT 20;

Karşınıza çıkan listede, yıllar önce sildiğiniz bir eklentiye ait (_transient_ içermeyen) devasa satırlar görüyorsanız, bunları silerek (veya autoload değerini ‘no’ yaparak) TTFB (İlk Bayt Süresi) değerinizi anında yarı yarıya düşürebilirsiniz.

2. WooCommerce Transients (Geçici Veriler) Çöplüğü

WooCommerce, müşterilerin sepet verilerini, kargo hesaplamalarını ve API yanıtlarını hızlandırmak için veritabanında “Transients” (Geçici Veriler) oluşturur. Ancak yoğun trafiği olan sitelerde zamanı dolan (Expired) bu veriler veritabanından otomatik olarak silinmeyebilir. wp_options tablosunun içinde on binlerce _transient_wc_ satırı birikir.

Kesin Çözüm: Eğer sunucunuzda SSH (Terminal) erişiminiz ve WP-CLI kuruluysa, tek bir komutla tüm bu geçici çöpü silebilirsiniz: wp transient delete --all

Eğer terminal erişiminiz yoksa, WooCommerce > Durum > Araçlar sekmesine giderek “WooCommerce geçici verilerini (transient) temizle” butonunu kullanabilirsiniz. Bu işlemi haftada bir kez yapmak, veritabanı şişmesini önleyecektir.

3. Gerçek Performans Mimarı: Redis Object Cache

Sayfa önbelleklemenin (HTML Caching) dinamik sayfalarda (Sepet/Ödeme) işe yaramadığını söylemiştik. İşte burada devreye Nesne Önbellekleme (Object Caching) girer.

Redis, veritabanına yapılan karmaşık MySQL sorgularını alır ve bunları sunucunun ultra hızlı belleğinde (RAM) tutar. Müşteri sepete tıkladığında, sunucu hantal sabit diske gidip MySQL tablolarını aramak yerine, sonucu saniyenin binde biri hızında RAM’den (Redis üzerinden) çeker.

WooCommerce’de Redis Nasıl Aktif Edilir?

1. Öncelikle hosting firmanızın sunucuda Redis servisini desteklediğinden ve PHP-Redis eklentisinin açık olduğundan emin olun (SaviorHost altyapısında bu standart olarak aktiftir).

2. WordPress panelinizden “Redis Object Cache” eklentisini (Till Krüss tarafından geliştirilen) kurun.

3. Eklentiyi etkinleştirmeden önce wp-config.php dosyanıza şu güvenlik ve performans satırlarını ekleyin:

   PHP

   define('WP_CACHE', true);
   define('WP_REDIS_PREFIX', 'siteadi_'); 
   define('WP_REDIS_MAXTTL', 86400);
   

4. Eklenti paneline gidip “Enable Object Cache” butonuna tıklayın.

Eğer Redis doğru yapılandırıldıysa, WooCommerce wp-admin panelinizdeki hızlanmayı ve ödeme sayfasındaki gecikmenin tamamen ortadan kalktığını saniyeler içinde hissedeceksiniz.

4. Donanımın Sınırları: Neden Sadece Optimizasyon Yetmez?

Yukarıdaki tüm veritabanı temizliğini yaptınız, Redis’i kurdunuz, eklentilerinizi optimize ettiniz. Ancak kampanya dönemlerinde veya anlık ziyaretçi sayınız 100’ü geçtiğinde siteniz hala kasılıyor veya 508 Resource Limit hatası mı veriyor?

Çünkü yazılım, donanımın izin verdiği yere kadar koşabilir.

Sektördeki standart hosting firmaları, maliyetleri düşürmek için hala yavaş dönüşlü SATA SSD’ler ve eski nesil Intel işlemciler kullanır. Redis ne kadar hızlı olursa olsun, RAM’in işlemciyle (CPU) iletişim kurma hızı yetersizse veritabanınız yine de tıkanır.

SaviorHost ile Darboğazı Donanımla Aşın

Biz SaviorHost olarak, WooCommerce sitelerinin ne kadar fazla I/O (Giriş/Çıkış) operasyonuna ihtiyaç duyduğunu biliyoruz. Bu yüzden altyapımızı e-ticaret siteleri için özel bir mühendislikle tasarladık:

• Gen4 NVMe Diskler (7GB/s Okuma/Yazma): Standart SSD’lerin 15 katı hıza sahip Gen4 NVMe disklerimiz sayesinde, veritabanı okuma ve yazma işlemlerindeki gecikmeleri (I/O Wait) tamamen ortadan kaldırıyoruz.

• AMD Ryzen™ 9 7900 DDR5 Altyapısı: İşlemcinin tek çekirdek performansının (IPC) yüksek olması, dinamik PHP sorgularının anında işlenmesini sağlar.

• Arka Planda Yük Yaratmayan KeyHelp: Ağır kontrol panellerinin RAM sömürmesini engelliyor, tüm belleği Redis’e ve sitenizin veritabanı sorgularına ayırıyoruz.

Sitenizin yavaşlığı nedeniyle sepeti terk eden müşterilerinize veda edin. E-ticaret operasyonunuzu Premium Linux Web Hosting paketlerimize taşıyın, 15 Gün İade Garantisi ile gerçek bir sunucunun WooCommerce’i nasıl uçurduğunu kendiniz deneyimleyin.

TTFB Nedir? Bir kullanıcı sitenize girmek için adresi yazdığında, tarayıcı sunucuya bir istek gönderir. Sunucunun bu isteği alıp, veritabanını tarayıp, ilk veri baytını ziyaretçinin tarayıcısına ulaştırdığı o ilk ana kadar geçen süreye TTFB denir. İdeal bir TTFB süresi 200 milisaniyenin (ms) altında olmalıdır.

TTFB Neden Yüksek Çıkar? Eğer sitenizin TTFB süresi 500ms ve üzerindeyse, resimlerinizi ne kadar küçültürseniz küçültün siteniz Google gözünde “yavaş” kabul edilir. Yüksek TTFB’nin üç ana nedeni vardır:

1. Yoğun ve optimize edilmemiş veritabanı sorguları.

2. İşletim sistemi ve arka planda çalışan hantal kontrol panellerinin işlemciyi yorması.

3. Sunucu işlemcisinin ve eski PHP sürümlerinin (bu konuda PHP 8.5’in performansa etkisini incelediğimiz yazımıza bakabilirsiniz) zayıf kalması.

TTFB Nasıl Düşürülür? Yazılımsal önbellekleme (Cache) TTFB’yi düşürmekte yardımcı olsa da kalıcı ve kesin çözüm güçlü bir altyapı mimarisinden geçer.

• Disk Okuma Hızı: Veritabanı sorgularının kuyrukta beklememesi için standart SSD’ler yerine saniyede 7GB/s’ye ulaşan Gen4 NVMe diskler kullanılmalıdır.

• İşlemci Gücü: Gelen isteklerin anında işlenip baytların saniyeler içinde yola çıkması için Ryzen 9 gibi yüksek tek çekirdek performanslı işlemciler gereklidir.

• Hafif Mimari: Sunucuyu yormayan KeyHelp paneli sayesinde arka plan servisleri minimumda tutularak kaynaklar sadece sitenize ayrılmalıdır.

Sitenizin SEO sıralamasını korumak ve organik trafiğinizi artırmak için yüksek TTFB sürelerine katlanmak zorunda değilsiniz. Yeni nesil SaviorHost sunucu altyapısıyla test edin ve aradaki performans farkını saniyeler içinde görün.

Bir web sitesi sahibinin karşılaşabileceği en sinir bozucu durumlardan biri, anlık trafik arttığında veya bir sipariş geldiğinde sitenin aniden çökmesi ve ekranda o meşhur “508 Resource Limit Is Reached” veya “CPU Quota Exceeded” hatasının belirmesidir.

Bu hata, paylaşımlı hosting ortamlarında CloudLinux (LVE Manager) veya benzeri sistemlerin, sitenizin diğer siteleri yavaşlatmasını engellemek için sizin fişinizi çekmesi anlamına gelir. Peki, WordPress neden bu kadar çok CPU tüketir ve bu darboğazı kod seviyesinde nasıl çözersiniz?

Kör uçuşu bırakıp, sorunu bir sistem yöneticisi (SysAdmin) gibi adım adım çözelim.

Adım 1: Darboğazı Teşhis Edin (Kör Uçuşuna Son)

CPU’nuzu neyin sömürdüğünü bilmeden eklenti silmek veya değiştirmek vakit kaybıdır. İlk olarak sorunun kaynağını bulmalısınız:

• Erişim Logları (Access Logs): Sunucu panelinizden (KeyHelp, cPanel vb.) erişim günlüklerini açın. Aynı saniye içinde yüzlerce kez xmlrpc.php veya wp-login.php dosyasına istek geliyorsa, sorun kodlarınızda değil, bir Brute Force (Kaba Kuvvet) saldırısındadır.

• Query Monitor Eklentisi: Sitenize geliştirici olarak giriş yapın ve Query Monitor eklentisini kurun. Hangi eklentinin veritabanına kaç saniye süren sorgular (Slow Queries) gönderdiğini milisaniyesine kadar tespit edin.

Adım 2: Heartbeat API ve admin-ajax.php Krizini Durdurun

WordPress, tarayıcı ile sunucu arasında sürekli bir iletişim kurmak için Heartbeat API’yi kullanır. Özellikle e-ticaret (WooCommerce) sitelerinde sepete ürün ekleme veya varyasyon seçme gibi işlemler admin-ajax.php üzerinden yürütülür. Anlık 50 kişinin sitede gezindiğini ve her saniye sunucuya bir AJAX isteği yolladığını düşünün. Düşük kapasiteli işlemciler bu kuyruğu eritemez ve CPU %100’e vurur.

Çözüm: Heartbeat API’nin frekansını düşürün veya gereksiz yerlerde tamamen kapatın. Temanızın functions.php dosyasına şu kodu ekleyerek Heartbeat’i sadece yazma ekranlarıyla sınırlandırabilirsiniz:

add_action( 'init', 'stop_heartbeat', 1 );
function stop_heartbeat() {
    global $pagenow;
    if ( $pagenow != 'post.php' && $pagenow != 'post-new.php' ) {
        wp_deregister_script('heartbeat');
    }
}

Adım 3: wp-cron.php‘yi Sunucu Tarafına Taşıyın

WordPress’in zamanlanmış görevleri (yazı yayımlama, yedek alma, e-posta gönderme) wp-cron.php üzerinden çalışır. Ancak WordPress, gerçek bir Cron sistemine sahip değildir; her ziyaretçi siteye girdiğinde bu dosya tetiklenir. Yüksek trafikli bir sitede her tıklamada wp-cron.php‘nin çalışması işlemcinizi felç eder.

Çözüm: WordPress’in sanal cron’unu kapatıp, gerçek sunucu cron’una geçin.

1. wp-config.php dosyanıza şu satırı ekleyerek sanal cron’u kapatın: define('DISABLE_WP_CRON', true);

2. Hosting panelinizin “Zamanlanmış Görevler” (Cron Jobs) bölümüne giderek şu komutu ekleyin (her 15 dakikada bir çalışacak şekilde): wget -q -O - https://siteniz.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Adım 4: Zombi Botları ve xmlrpc.php‘yi Engelleyin

xmlrpc.php, WordPress’in dış uygulamalarla (örneğin mobil uygulama) iletişim kurmasını sağlar. Ancak günümüzde hackerların DDoS saldırıları ve şifre denemeleri için en çok kullandığı arka kapıdır. Sunucunuz bu istekleri yanıtlamaya çalışırken CPU limitini doldurur.

Çözüm: Eğer WordPress mobil uygulamasını veya Jetpack gibi dış servisleri kullanmıyorsanız, .htaccess dosyanıza şu kodu ekleyerek bu dosyaya erişimi kökten kapatın:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Adım 5: Acı Gerçek: Sorun Yazılımda Değil, Donanımınızda Olabilir

Yukarıdaki tüm optimizasyonları yaptınız, eklentilerinizi azalttınız, Redis Object Cache kurup veritabanı sorgularını RAM’e aldınız ama hala CPU sınırına takılıyorsanız… Artık yazılımın sınırlarına geldiniz demektir.

Sektördeki birçok standart hosting firması, sunucularında çok çekirdekli ancak tek çekirdek performansı (IPC) çok zayıf olan eski nesil Intel Xeon işlemciler kullanır. Dahası, tek bir sunucuya yüzlerce site doldurarak size sadece “kağıt üzerinde” kaynak ayırırlar. Ağır bir WooCommerce veya Elementor tabanlı siteniz varsa, bu işlemciler PHP kuyruklarını (Workers) eritemez.

SaviorHost ile “Limitlere” Veda Edin

Biz SaviorHost olarak, CPU darboğazını eklentilerle saklamaya çalışmıyoruz; saf donanım gücüyle eziyoruz.

• AMD Ryzen™ 9 7900 İşlemci Gücü: Saat döngüsü başına işlem (IPC) gücü inanılmaz yüksek olan Ryzen 9 mimarisi sayesinde, ağır PHP betikleri ve dinamik veritabanı sorguları milisaniyeler içinde işlenir. CPU şişmez, sıraya girmez.

• Ultra Hafif KeyHelp Mimarisi: Arka planda RAM ve işlemcinizi sömüren hantal kontrol panelleri (cPanel vb.) yerine, donanımın %99’unu doğrudan web sitenize tahsis eden Alman harikası KeyHelp mimarisini kullanıyoruz.

• Cömert PHP Worker Sayısı: E-ticaret sitelerinizin “admin-ajax” kuyruklarında boğulmaması için paketlerimizde rakiplerin sunmadığı düzeyde 50 PHP Worker limiti sunuyoruz.

Eğer CPU limitleriyle savaşmaktan, sitenizi sürekli optimize etmeye çalışıp yine de 508 hatası almaktan yorulduysanız; yeni nesil Yüksek Performanslı Linux Hosting veya WordPress Hosting altyapımıza geçiş yapın.

Donanım limitlerini düşünmeyi bırakın, sadece projenizi büyütmeye odaklanın. Farkı 15 Gün Koşulsuz İade Garantisi ile sıfır riskle test edebilirsiniz!

Son yıllarda PHP 8 serisi ile (özellikle JIT – Just In Time Compiler mimarisiyle) gelen devrim niteliğindeki yenilikler, PHP 8.5 ile çok daha kusursuz bir hale geldi. Peki, eski bir sürümden güncel sürümlere geçmek sitenize ne kazandırır?

1. CPU ve Bellek (RAM) Optimizasyonu Güncel PHP sürümleri, kodu makine diline çevirirken çok daha agresif optimizasyonlar yapar. Aynı işlemi yapmak için %30’a varan oranda daha az RAM kullanır ve CPU’yu çok daha az meşgul eder. Bu, anlık trafik artışlarında (hit dalgalanmalarında) sunucunuzun çökmesini engeller.

2. Daha Hızlı Kod İşleme (Execution Time) Özellikle WooCommerce ödeme adımlarında yavaşlık yaşayan sitelerde veya ağır Laravel projelerinde, güncel sürümler sorguları çok daha kısa sürede işler. Bu hız artışı, ziyaretçi deneyimini doğrudan iyileştirir.

3. Üst Düzey Güvenlik Eski PHP sürümleri yeni keşfedilen güvenlik açıklarına karşı yama almaz. Sitenizi güncel bir PHP sürümünde barındırmak, veritabanı sızıntılarına karşı en güçlü ilk savunma hattıdır.

Panel Hantallığına Takılmayın Sektördeki birçok hosting firması, kullandıkları kontrol panellerinin (CWP vb.) hantallığı ve güncelleme almaması nedeniyle müşterilerini eski PHP sürümlerine mahkum bırakabiliyor. SaviorHost altyapısındaki Linux web hosting paketlerimizde kullandığımız Alman harikası KeyHelp kontrol paneli, güncel PHP sürümlerini anında ve stabil bir şekilde destekler.

AMD Ryzen™ 9 işlemcilerimizin sağladığı devasa gücü, en güncel PHP mimarisiyle birleştirerek yazılımlarınızın sınırlarını zorlayabilirsiniz.

Peki, ana sayfada harikalar yaratan bu önbellek (cache) eklentilerine ödeme adımında ne oluyor?

Bypass Cache (Önbelleğin Devre Dışı Kalması) Önbellek eklentileri, web sitenizin statik bir kopyasını (HTML halini) oluşturup ziyaretçiye sunar. Böylece sunucu yorulmaz. Ancak bir müşteri sepete ürün eklediğinde, sisteme giriş yaptığında veya stok düşüleceği zaman sistemin “dinamik” çalışması gerekir. Eklenti burada aradan çekilir ve tüm yük doğrudan sunucunuzun çıplak donanımına biner. Bu durum doğrudan sunucu yanıt sürenizi, yani TTFB (İlk Bayt Süresi) değerinizi aniden yükseltir.

Asıl Darboğaz Nerede Başlıyor? Önbellek aradan çekildiği o kritik saniyelerde sitenizin hızı tamamen iki şeye bağlıdır:

1. PHP Yorumlama Hızı: PHP işçilerinin o anki hesaplamayı ne kadar hızlı yapabildiği.

2. Disk I/O (Okuma/Yazma): MariaDB veya MySQL veritabanının diske sipariş verisini ne kadar sürede yazabildiği.

Eğer sunucunuzda eski nesil Xeon işlemciler ve standart SSD diskler kullanılıyorsa, müşteri o sepet sayfasında bekler ve genellikle sepeti terk eder (Cart Abandonment).

Çözüm: Saf Donanım Gücü Dinamik sayfaların yavaşlığını eklentilerle çözemezsiniz. SaviorHost olarak e-ticaret altyapılarında sıfır gecikme (zero-latency) prensibiyle çalışıyoruz. Dinamik sorguların anında işlenmesi için tek çekirdek performansı tavan yapan AMD Ryzen™ 9 7900 işlemciler kullanıyoruz.

Ayrıca sunucuyu yoran hantal kontrol panelleri yerine ultra hafif KeyHelp mimarisiyle donanım gücünün %100’ünü doğrudan e-ticaret sitenize aktaran yüksek performanslı WordPress hosting paketlerimizle sepet terk edilme oranlarınızı minimuma indiriyoruz.

Sepette müşteri kaybetmek istemiyorsanız, önbelleğin arkasına saklanmayan gerçek donanım gücüyle tanışın.

Ancak teknoloji yerinde durmuyor. Son dönemde yaptığımız teknik analizler ve müşteri geri bildirimleri, CWP’nin artık SaviorHost’un hız ve güvenlik standartlarına ayak uyduramadığını gösterdi. Altyapımızı tamamen Alman mühendisliği ürünü olan KeyHelp kontrol paneline taşıma kararımızın arkasında yatan gerçek teknik sebepleri sizlerle şeffafça paylaşmak istiyoruz.

Neden Değişim Kararı Aldık? (CWP’nin Çöküş Dönemi)

1. Güncelleme Kıtlığı ve Kronikleşen Hatalar (Bugs)

Bir kontrol panelinin kalbi, aldığı düzenli güvenlik ve stabilite güncellemeleridir. CWP’de son zamanlarda güncellemelerin durma noktasına gelmesi, geldiğinde ise “bir yeri onarırken başka bir fonksiyonu bozması” (Regression Bugs) sistem yöneticileri için kabusa dönüştü. Çözülmeyen kronik hatalar yüzünden sunucuya sürekli manuel müdahale etmek zorunda kalmak, %99.9 uptime felsefemizle uyuşmuyordu.

2. Teknoloji Duvarı: PHP Sürüm Tıkanıklığı

Bugün modern web projeleri (özellikle Laravel ve güncel WordPress mimarileri) yüksek performans için PHP 8.4 ve PHP 8.5 gibi en güncel sürümlere ihtiyaç duyuyor. CWP’nin geliştirme döngüsünün yavaşlaması nedeniyle PHP 8.3’te takılıp kalması, geliştirici müşterilerimizin projelerini zincirleyen bir engele dönüştü. KeyHelp ise en yeni PHP sürümlerini çıktığı gün stabil olarak sunarak bu duvarı yıktı.

3. CentOS / AlmaLinux Kargaşası

CWP’nin omurgasını oluşturan CentOS serisinin fişinin çekilmesi (EOL) ve topluluğun AlmaLinux/RockyLinux arasında bölünmesi, geleceğe dair ciddi bir belirsizlik yarattı. Biz ise rotamızı dünyanın en stabil ve uzun ömürlü işletim sistemi altyapısına, yani Ubuntu ve Debian‘a (KeyHelp’in native desteklediği mimariye) çevirdik.

CWP vs. KeyHelp: Teknik Karşılaştırma Tablosu

Müşterilerimize “Neden KeyHelp?” sorusunun cevabını net verilerle sunmak istiyoruz:

Sonuç: Geleceğe Yatırım

CWP bize geçmişte iyi hizmet etti, ancak SaviorHost’un geleceğindeki “Sınır Tanımayan Güç” vizyonuna ayak uyduramadı.

Şu an tüm sunucularımızda, AMD Ryzen™ 9 7900 işlemcilerin ham gücünü ve Gen4 NVMe disklerin 7GB/s’lik hızını, KeyHelp’in pürüzsüz mimarisiyle birleştiriyoruz. Sitenizin arka plandaki hatalar yüzünden değil, gerçekten hak ettiği hızda çalışmasını istiyorsanız, teknik ekibimizin titizlikle optimize ettiği yeni nesil altyapımızı deneyimleyebilirsiniz.

👉 KeyHelp Panelli Yeni Nesil Linux Web Hosting Paketlerimizi İnceleyin

Eğer sitenizin altyapısı için bir arayışındaysanız, sunucu kaynaklarınızı hantal bir panele mi yoksa doğrudan ziyaretçilerinize mi harcamak istediğinize karar vermelisiniz. Bu yazımızda, sektörün tekelini kıran Alman mühendisliği harikası Keyhelp ile yılların yorgunu cPanel‘i teknik bir masaya yatırıyoruz.

cPanel Neden Artık Bir “Kaynak Canavarı”?

cPanel, on yılı aşkın süredir sektöre yön veren, özellik bakımından oldukça zengin bir sistemdir. Ancak bu “her şeyi yapabilme” takıntısı, beraberinde devasa bir hantallığı da getirdi.

• Arka Plan Yükü: cPanel, sadece arka planda çalışır durumda kalabilmek (idle state) için ciddi bir RAM ve CPU döngüsü tüketir. Sitenize henüz tek bir ziyaretçi bile girmeden sunucunuzun kaynaklarının bir kısmı panele feda edilir.

• Lisans Maliyetleri: Sürekli artan lisans ücretleri, hosting firmalarının donanım kalitesinden kısıp lisans parasını ödemesine veya bu maliyeti doğrudan müşteriye yansıtmasına neden olur.

Keyhelp: Performans Odaklı Alman Minimalizmi

Keyhelp, gücünü sadeliğinden ve mükemmel kod optimizasyonundan alan yeni nesil bir sunucu yönetim panelidir. Sadece ihtiyaç duyulan servisleri en verimli şekilde çalıştıracak bir mimariyle tasarlanmıştır.

• Ultra Düşük Kaynak Tüketimi: Keyhelp, sunucu belleğinde (RAM) ve işlemcide (CPU) yok denecek kadar az yer kaplar. Bu sayede sunucunuzun saf gücü panele değil; veri tabanı sorgularınıza, e-ticaret sitenizin ödeme adımlarına ve anlık trafik dalgalanmalarına ayrılır.

• Modern ve Temiz Arayüz: Geliştiriciler ve son kullanıcılar için karmaşadan uzak, sadece birkaç tıklamayla SSL kurulumu, e-posta yönetimi ve FTP erişimi sağlayan sezgisel bir yapı sunar.

Teknik Karşılaştırma Matrisi

Aşağıdaki tablo, iki panel arasındaki temel felsefe farkını net bir şekilde özetlemektedir:

AMD Ryzen 9 7900 ve Keyhelp Sinerjisi

Bir kontrol panelinin hafif olması tek başına yeterli değildir; altındaki donanımın da bu hafifliği uçuşa çevirecek kadar güçlü olması gerekir. Tam bu noktada devreye Saviorhost‘un tavizsiz donanım mimarisi giriyor.

Almanya Contabo veri merkezinin sarsılmaz altyapısında konumlandırdığımız sunucularımız, çoklu işlem parçacığı (multi-threading) konusunda sektörün zirvesinde yer alan AMD Ryzen 9 7900 işlemcilerle çalışır.

• Linux Hosting paketlerimizde Keyhelp’in sıfıra yakın kaynak tüketimi, Ryzen 9’un ham işlemci gücüyle birleştiğinde; özel yazılımlarınız ve ajans projeleriniz için darboğazsız (bottleneck-free) bir deneyim yaşatır.

• Eğer ağır eklentiler kullanan bir blog veya e-ticaret siteniz varsa, veritabanı sorgularının en hızlı şekilde işlenmesi hayati önem taşır. Keyhelp ile optimize edilmiş WordPress Hosting paketlerimiz, panelin aradan çekilip tüm sunucu gücünün sitenize akmasını sağlayarak sayfa açılış sürelerinizi milisaniyelere düşürür.

Sonuç: Kaynaklarınızı Ziyaretçilerinize Saklayın

2026 yılının rekabetçi web ekosisteminde, Google algoritmaları sitenizi milisaniyelerle yargılarken sunucu kaynaklarınızı hantal kontrol panellerine kurban edemezsiniz. %99 uptime oranı, Alman veri merkezi stabilitesi ve Ryzen 9 işlemcilerin gücüyle desteklenen gerçek bir hızlı hosting deneyimi arıyorsanız, cPanel’in alışkanlık tuzağından çıkıp Keyhelp’in modern mimarisiyle tanışmanın tam zamanı.

Aşağıdaki rehber, en hızlı geri dönüş için önce teşhis, ardından kalıcı çözüm adımlarını sunar. Geliştirici olmanıza gerek yok—adımları sırayla uygulamanız yeterli.

1) İlk Teşhis: Hatanın Gerçek Yüzünü Görün (Debug Mode)

500’ün “neden”ini görmek için Debug Mode’u açın. Yönetim paneline erişebiliyorsanız Gelişmiş Parametreler → Performans → Hata Ayıklama Modu (Debug Mode) bölümünden aktif edin; erişemiyorsanız config/defines.inc.php dosyasında _PS_MODE_DEV_ değerini true yapın. İşiniz bitince mutlaka kapatın. (Resmi yardım merkezi ve topluluk kılavuzları bunu önerir.) help-center.prestashop.com+1

Neyi beklemelisiniz?
Beyaz sayfa yerine ayrıntılı PHP/Symfony hata yığını göreceksiniz. Satır ve dosya adı, sorunun modül/tema/çekirdek kaynaklı olup olmadığını açık eder.

2) En Sık Nedenler ve Hızlı Çözümler

A) Tema/Modül Çatışmaları (Güncelleme Sonrası)

• Belirti: 500, BO/FO’da aniden çökme.

• Çözüm: Son kurduğunuz modülü FTP ile /modules/ altında geçici olarak yeniden adlandırın (devre dışı kalır). Ardından önbelleği temizleyip sayfayı yenileyin. PrestaShop’un genel 500 hata kılavuzu modül kaynaklı çöküşleri özel olarak vurgular. help-center.prestashop.com

B) PHP Sürümü / Eklenti Uyumsuzluğu

• Belirti: Hata yığında Deprecated, Fatal error: Uncaught TypeError vb.

• Çözüm: Kullanılan PrestaShop sürümünün PHP uyumluluğunu kontrol edin. PrestaShop 8 için öneri PHP 8.1’dir; sistem gereksinimleri resmi dökümantasyonda detaylıdır. Ayrıca intl gibi eklentilerin yüklü olduğundan emin olun. PrestaShop

C) Dosya/klasör izinleri hatalı (permissions)

• Belirti: Log dizinine yazılamıyor, cache temizlenmiyor → 500.

• Çözüm: Tipik olarak dosyalar 644, klasörler 755 olmalı; özellikle var/cache ve var/logs (veya /var/log) yazılabilir olmalı. Toplulukta izin/ownership kaynaklı 500’ler sıkça görülür. prestashop.com

D) Bozulmuş .htaccess veya URL Yeniden Yazımı (mod_rewrite)

• Belirti: Friendly URL açıkken 500/404, yönlendirme döngüsü.

• Çözüm: .htaccess dosyasını yeniden üretin ve sunucuda URL rewrite’ın aktif olduğundan emin olun. PrestaShop 8 kullanıcı kılavuzu Friendly URL’lerin URL rewriting gerektirdiğini özellikle belirtir. docs.prestashop-project.org

E) Önbellek/Smarty Bozulmaları

• Belirti: Sayfalar açılmıyor ya da eski halini gösteriyor.

• Çözüm: BO’dan Performans → Önbellek temizle; erişemiyorsanız var/cache/prod ve var/cache/dev içeriğini silin (dizini değil, içeriği). Barındırma sağlayıcı rehberleri manuel temizlemeyi adım adım gösterir. SiteGround

3) Adım Adım “Hızlı Kurtarma” Akışı (How-To)

1. Debug Mode’u açın ve ekranda görünen gerçek hatayı not alın. (Sebebi netleştirir.) help-center.prestashop.com

2. Son değişikliği geri alın: Yeni modül/tema/sürüm güncellemesi yaptıysanız kapatın veya geri sarın. help-center.prestashop.com

3. Önbelleği temizleyin: BO → Performans’tan; erişemiyorsanız var/cache/prod/* ve var/cache/dev/* klasörlerinin içeriğini silin. SiteGround

4. .htaccess’i yeniden oluşturun: BO → Mağaza Parametreleri → Trafik & SEO → Friendly URL’yi kapatıp kaydedin, sonra tekrar açıp kaydedin (yeniden yazım aktif olmalı). docs.prestashop-project.org

5. PHP sürümü ve eklentileri doğrulayın: PrestaShop 8 için öneri PHP 8.1; intl, mbstring, gd, curl, zip gibi yaygın eklentileri kontrol edin (eksikler 500’e yol açabilir). PrestaShop

6. İzin/ownership’i düzeltin: Özellikle var/ altındaki yazılabilir dizinler (cache/log) için kullanıcı ve izinleri kontrol edin. (Topluluk çözümleri sıkça buna işaret eder.) prestashop.com

7. Kalıcı sorunlarda log’lara bakın: Yönetim → Gelişmiş Parametreler → Günlükler (Logs) ve sunucudaki var/log dosyaları ipucu verir. (Resmi 1.7 kılavuzu log sayfasını açıklar.) docs.prestashop-project.org

İpucu: Yerel/uzak sunucunuzun uyumluluğunu topluca test etmek için PrestaShop’un resmi PhpPsInfo aracını çalıştırabilirsiniz (gereksinim kontrolü). GitHub

4) Örnek Senaryo ve Çözüm (Kopyala–Yapıştır)

Belirti: Tema güncellemesi sonrası tüm sayfalarda 500.

Çözüm Planı:

5) Kalıcı Sağlamlık: “Bir daha yaşanmaması” için 6 öneri

1. Sürüm uyum tablosuna göre güncelleyin: PHP/PrestaShop uyumunu kontrol etmeden sürüm yükseltmeyin. PrestaShop

2. Staging ortamı kullanın: Modül/tema güncellemelerini önce test mağazasında deneyin.

3. Düzenli yedek alın: Dosya + veritabanı.

4. İzin politikası: Dosyalar 644, klasörler 755; var/ altı yazılabilir. prestashop.com

5. Önbellek stratejisi: Büyük değişikliklerden sonra cache temizliği rutine bağlansın. SiteGround

6. Güncel intl/ICU ve gerekli eklentiler: Yerelleştirme ve tarih/sayı biçimleri için kritik. PrestaShop

SSS (Kısa)

500 hatası neden olur?
En çok modül/tema uyumsuzluğu, PHP sürüm/eklenti uyumsuzluğu, bozuk .htaccess, yanlış izinler ve bozuk cache yüzünden. Resmi yardım merkezi bu başlıkları kapsıyor. help-center.prestashop.com

Önbelleği elle nasıl temizlerim?
Yönetim yoksa var/cache/prod/* ve var/cache/dev/* içeriğini silin; ardından siteyi yenileyin. SiteGround

Friendly URL açıkken 500/404 alıyorum, ne yapmalıyım?
URL yeniden yazımı (mod_rewrite) aktif mi kontrol edin; Friendly URL’yi kapat–kaydet–aç–kaydet yaparak .htaccess’i yeniden oluşturun. docs.prestashop-project.org

Hangi PHP sürümünü kullanmalıyım?
PrestaShop 8 için öneri PHP 8.1’dir (güncel resmi dökümantasyona göre). PrestaShop