Hestiacp'de Site Hızlandırma — Nginx Önbellekleme, Php-Fpm ve Redis Ayarları

[AnestezyAnestezy is verified member.]

Seride şu ana kadar HestiaCP'yi kurduk, cPanel'den site taşıdık ve otomatik uzak yedekleme kurduk. Sıra sunucudan gerçekten performans almaya geldi.

HestiaCP varsayılan ayarlarıyla çalışır ama hiçbir şekilde optimize gelmez. Varsayılan kurulumda Nginx sadece Apache'ye proxy yapar, PHP-FPM işlem sayısı düşük tutulur, önbellekleme kapalıdır. Bu rehberdeki ayarları uyguladığında aynı donanımda sitenin belirgin şekilde hızlanır ve çok daha fazla eşzamanlı ziyaretçi kaldırır.

Örneklerde kullanıcı adı olarak oblifex kullanıyorum, sen kendi kullanıcı adını yazacaksın.

Uyarıdan başlayalım: Bu ayarlara girmeden önce sunucunun yedeğini al. Yanlış bir PHP-FPM değeri sunucunun belleğini bitirip siteni tamamen kapatabilir.

---

1. Önce ölç, sonra değiştir

Rastgele ayar kurcalamak zaman kaybıdır. Önce darboğazın nerede olduğunu bul.

Sunucunun anlık yükünü gör:

apt install -y htop
htop

Bellek durumu:

free -h

Disk okuma/yazma darboğazı var mı:

apt install -y sysstat
iostat -x 2 5

En çok kaynak yiyen süreçler:

ps aux --sort=-%mem | head -10

Bu çıktılara göre yön belirle:

• CPU sürekli %100 ise → PHP kodu ya da veritabanı sorguları sorunlu, önbellekleme şart
• Bellek doluysa → PHP-FPM işlem sayısı fazla ya da MySQL ayarları şişkin
• Disk beklemesi (wa) yüksekse → önbellekleme ve Redis şart
• Her şey boşta ama site yavaşsa → sorun sunucuda değil, kodda veya harici isteklerde

---

2. Nginx + Apache mimarisini anlamak

HestiaCP varsayılan olarak iki web sunucusunu birlikte çalıştırır:

• Nginx önde durur, statik dosyaları (resim, CSS, js) doğrudan servis eder
• Apache arkada durur, PHP isteklerini işler

Bu yapı .htaccess desteği verdiği için uyumluluğu yüksektir ama iki kat bellek tüketir. Eğer sitende .htaccess bağımlılığı yoksa Apache'yi tamamen devre dışı bırakıp sadece Nginx + PHP-FPM kullanmak en büyük performans kazancını sağlar.

Apache'siz moda geçmek için domainin backend template'ini değiştir:

v-change-web-domain-proxy-tpl oblifex oblifex.com wordpress
v-change-web-domain-backend-tpl oblifex oblifex.com PHP-8_3

Sunucuda hiç Apache kullanmayacaksan tamamen kapatabilirsin, ciddi bellek kazanırsın:

systemctl stop apache2
systemctl disable apache2
v-change-sys-web-backend nginx

Dikkat: Bu geri dönüşü zahmetli bir işlemdir. Üzerinde eski, .htaccess bağımlı yazılımlar barındıran bir sunucuda yapma.

---

3. Nginx FastCGI önbelleklemesi

Bu, tek başına en büyük hız artışını sağlayan ayardır. PHP'nin ürettiği HTML çıktısını bellekte tutar; aynı sayfa ikinci kez istendiğinde PHP hiç çalışmaz, veritabanına hiç gidilmez.

3.1 Önbellek alanını tanımla

nano /etc/nginx/conf.d/fastcgi_cache.conf

İçine şunu yaz:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=OBLIFEX:100m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header updating http_500 http_503;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
add_header X-Cache-Status $upstream_cache_status;

Önbellek dizinini oluştur:

mkdir -p /var/cache/nginx
chown -R www-data:www-data /var/cache/nginx

3.2 Domaine özel kural ekle

HestiaCP'de domaine özel Nginx ayarları .conf uzantılı ek dosyalara yazılır; böylece panel şablonu yeniden oluşturduğunda ayarların silinmez.

nano /home/oblifex/conf/web/oblifex.com/nginx.conf_cache

İçerik:

set $skip_cache 0;

if ($request_method = POST) { set $skip_cache 1; }
if ($query_string != "") { set $skip_cache 1; }
if ($request_uri ~* "/admin.php|/wp-admin/|/login|/cart|/checkout|/sepet") { set $skip_cache 1; }
if ($http_cookie ~* "xf_user|wordpress_logged_in|woocommerce_items_in_cart") { set $skip_cache 1; }

location ~ \.php$ {
    fastcgi_cache OBLIFEX;
    fastcgi_cache_valid 200 301 302 60m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
}

Buradaki skip_cache kuralları hayati önemde. Giriş yapmış kullanıcılara ve sepet/ödeme sayfalarına önbellek uygulanırsa bir kullanıcının sayfası başka kullanıcıya gösterilir. Kullandığın yazılımın oturum çerezini bu listeye eklediğinden emin ol:

Yazılım	Oturum çerezi
XenForo	xf_user, xf_session
WordPress	wordpress_logged_in, comment_author
WooCommerce	woocommerce_items_in_cart, wp_woocommerce_session
OpenCart	OCSESSID
Laravel	laravel_session

Ayarları uygula:

nginx -t
systemctl reload nginx

3.3 Önbelleğin çalıştığını doğrula

curl -I https://oblifex.com

Çıktıda X-Cache-Status: MISS görürsün. Komutu bir kez daha çalıştır; artık HIT yazmalı. HIT Gördüğün an o sayfa artık PHP'yi hiç çalıştırmıyor demektir.

Önbelleği temizlemek için:

rm -rf /var/cache/nginx/*
systemctl reload nginx

---

4. PHP-FPM ayarları

Varsayılan PHP-FPM ayarları küçük sunucular için yazılmıştır. Yoğun bir sitede işlem havuzu dolar ve ziyaretçiler "502 Bad Gateway" görür.

Ayar dosyasını aç:

nano /etc/php/8.3/fpm/pool.d/oblifex.conf

Kritik satırlar şunlar:

pm = dynamic
pm.max_children = 30
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
pm.max_requests = 500

Max_children değerini nasıl hesaplarsın?

Formül basit:

max_children = (Kullanilabilir RAM - Diger servisler) / Ortalama PHP islem boyutu

Ortalama PHP işlem boyutunu şöyle ölçersin:

ps -ylC php-fpm8.3 --sort:rss | awk '{sum+=$8; n++} END {print sum/n/1024 " MB"}'

Diyelim çıktı 45 MB geldi ve sunucunda 4 GB RAM var. MySQL ve sisteme 1,5 GB ayırırsan PHP'ye 2,5 GB kalır:

2500 / 45 = yaklasik 55

Kaba bir referans tablosu:

Sunucu RAM	max_children (yaklaşık)
2 GB	15 – 20
4 GB	35 – 50
8 GB	80 – 100
16 GB	160 – 200

Bu değeri şişirme. Çok yüksek bir max_children trafiği kaldırmaz, sadece yoğunlukta sunucunun belleğini bitirip OOM killer'ın MySQL'i kapatmasına yol açar; site tamamen çöker.

Değişikliği uygula ve havuzu izle:

systemctl restart php8.3-fpm
tail -f /var/log/php8.3-fpm.log

Logda server reached pm.max_children setting uyarısı görüyorsan değeri kademeli artır. Görmüyorsan dokunma.

---

5. OPcache — PHP'nin kendi hızlandırıcısı

OPcache, PHP kodunu her istekte yeniden derlemek yerine derlenmiş hâlini bellekte tutar. Genelde kurulu gelir ama ayarları düşüktür.

nano /etc/php/8.3/fpm/conf.d/10-opcache.ini

Önerilen değerler:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.validate_timestamps=1
opcache.save_comments=1
opcache.jit_buffer_size=64M
opcache.jit=tracing

systemctl restart php8.3-fpm

Aktif olduğunu doğrulamak için:

php -i | grep opcache.enable

Not: Geliştirme yaptığın bir sunucuda validate_timestamps=0 yapma; kod değişikliklerin yansımaz, saatlerce "neden değişmiyor" diye uğraşırsın.

---

6. Redis kurulumu

Redis, veritabanı sorgu sonuçlarını ve oturum verilerini bellekte tutar. Forum ve e-ticaret gibi veritabanı yoğun sitelerde fark çok belirgindir.

apt install -y redis-server php8.3-redis
systemctl enable --now redis-server

Bellek sınırı koy, yoksa Redis zamanla tüm RAM'i yer:

nano /etc/redis/redis.conf

Şu satırları bul ve ayarla:

maxmemory 512mb
maxmemory-policy allkeys-lru

systemctl restart redis-server
systemctl restart php8.3-fpm

Çalışıyor mu kontrol et:

redis-cli ping

PONG Cevabı gelmeli.

PHP oturumlarını Redis'e taşı

nano /etc/php/8.3/fpm/php.ini

session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379"

Yazılım tarafı

XenForo için src/config.php dosyasına ekle:

$config['cache']['enabled'] = true;
$config['cache']['provider'] = 'Redis';
$config['cache']['config'] = [
    'host' => '127.0.0.1',
    'port' => 6379
];

WordPress için Redis Object Cache eklentisini kur ve etkinleştir, ek ayara gerek yok.

---

7. MySQL / MariaDB ayarları

Varsayılan MariaDB ayarları çok muhafazakârdır. En kritik değer innodb_buffer_pool_size; veritabanının ne kadarının bellekte tutulacağını belirler.

nano /etc/mysql/mariadb.conf.d/50-server.cnf

[mysqld] Bölümüne ekle:

innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 2
max_connections = 150
tmp_table_size = 64M
max_heap_table_size = 64M
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

innodb_buffer_pool_size İçin kural: veritabanı toplam boyutundan biraz büyük, ama sunucu RAM'inin yarısını geçmeyecek şekilde ayarla.

systemctl restart mariadb

Bir hafta çalıştırdıktan sonra ayarlarını denetlemek için:

wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
perl mysqltuner.pl

Bu script hangi değerin düşük kaldığını doğrudan söyler. Ayrıca slow.log dosyasını incele; sitenin yavaşlığı çoğu zaman tek bir indekslenmemiş sorgudan kaynaklanır.

---

8. Gzip, Brotli ve tarayıcı önbelleği

Sıkıştırma, sunucu yükünü artırmadan sayfa boyutunu ciddi oranda düşürür.

nano /etc/nginx/conf.d/gzip.conf

gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied any;
gzip_types text/plain text/css text/xml application/json application/javascript application/xml+rss image/svg+xml;

Statik dosyalar için tarayıcı önbelleği, domainin ek conf dosyasına:

location ~* \.(jpg|jpeg|png|gif|webp|avif|ico|css|js|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
    access_log off;
}

nginx -t && systemctl reload nginx

---

9. Sonucu ölç

Değişikliklerin işe yarayıp yaramadığını sayıyla gör. Sunucunun kendi üzerinden ham yanıt süresini ölç:

curl -o /dev/null -s -w "Toplam: %{time_total}s | Ilk byte: %{time_starttransfer}s\n" https://oblifex.com

Yük testi için:

apt install -y apache2-utils
ab -n 500 -c 20 https://oblifex.com/

Sayfanın tarayıcı tarafındaki performansı için PageSpeed Insights ve GTmetrix kullan. Ama şunu unutma: sunucu optimizasyonu skorun sadece bir kısmıdır. Optimize edilmemiş görseller, aşırı JavaScript ve üçüncü parti scriptler sunucuyla ilgili değildir, tema tarafında çözülür.

---

Sık karşılaşılan hatalar

Önbellek açtım, giriş yapmış kullanıcılar başkasının sayfasını görüyor
skip_cache Çerez listesi eksik. Kullandığın yazılımın oturum çerezini mutlaka ekle. Bu ciddi bir güvenlik sorunudur, hemen düzelt.

502 Bad Gateway alıyorum
PHP-FPM havuzu dolmuş ya da servis çökmüş. systemctl status php8.3-fpm İle bak, max_children uyarısı varsa değeri artır.

Ayar yaptım ama değişiklik yansımıyor
Panel şablonunu yeniden oluşturunca dosyaların silinmiştir. Domaine özel ayarları nginx.conf_ ile başlayan ek dosyalarda tut, ana nginx.conf dosyasını doğrudan düzenleme.

MariaDB açılmıyor
innodb_buffer_pool_size Değeri mevcut RAM'den büyük olabilir. journalctl -u mariadb -n 50 İle gerçek hatayı gör, değeri düşür.

Sunucu yeniden başladıktan sonra site yavaşladı
Önbellek boşaldı, doğal. Birkaç dakika trafik aldıktan sonra tekrar hızlanır.

Redis kurdum ama fark yok
Yazılım tarafında etkinleştirmemişsindir. redis-cli monitor Çalıştırıp siteyi gezin; ekranda hareket yoksa yazılım Redis'i kullanmıyordur.

---

Optimizasyonda altın kural: tek seferde tek değişiklik yap ve ölç. Beş ayarı birden değiştirip site bozulunca hangisinin sorun çıkardığını asla bulamazsın.

Sunucunuzun htop çıktısını ve site boyutunu buraya yazarsanız size özel değerler önerebilirim. Serinin devamında HestiaCP'de sunucu güvenliğini sıkılaştırma konusunu işleyeceğim.