Sunucu Optimizasyonu: Web Sitesi Hızını Artırma Yolları

Sunucu Optimizasyonu: Web Sitesi Hızını Artırma Yolları

Web sitesi yavaş açılıyorsa, çoğu zaman sorun "sayfanın HTML/CSS'i" değildir. Asıl darboğaz sunucunun kendisindedir: Linux kernel TCP parametreleri varsayılan değerlerde, PHP-FPM pool kaynak sıkışıyor, OPcache cache miss oranı yüksek, MariaDB innodb_buffer_pool_size yetersiz, disk I/O scheduler NVMe için yanlış ayarlı, ya da CPU governor güç tasarrufu modunda. Bu yazı sıradan bir "CDN kullanın, gzip açın" rehberi değil. Sunucu seviyesinde (web framework ve sayfa içeriği tarafından ayrı) ne tune edilmesi gerektiğini bir VDS/dedicated sahibi gözüyle anlatıyor.

Eğer Core Web Vitals (LCP, INP, CLS) metriklerinin frontend tarafını okumak istiyorsanız Core Web Vitals 2026 rehberi ve sayfa hızı: WordPress vs Next.js yazılarımıza bakın. Hosting altyapısının SEO'ya etkisi için hosting ve SEO ilişkisi yazımız var. MySQL özelinde index ve sorgu performansı için MySQL performans rehberi. Bu yazıdaysa Linux sunucunun kendisini nasıl tune edeceğinize odaklanıyoruz.

Buyukweb perspektifi: VDS sunucu paketlerimizde E5-V4 sınıfı Intel Xeon CPU (E5-2680 / E5-2697 V4), NVMe SSD disk ve KVM tam virtualization ile root erişim sağlıyoruz. Bu yazıdaki sysctl, my.cnf, PHP-FPM pool ve OPcache ayarlarının tamamını kendi VDS'inizde uygulayabilirsiniz. cPanel paylaşımlı paketlerimizde ise LiteSpeed + LSCache + CloudLinux LVE kombinasyonu hazır gelir — kullanıcı seviyesinde tuning gerekmez. Bursa Tier 3 veri merkezi + DDoS L3/L4/L7 koruma + Veeam günlük yedek (VDS) altyapı katmanını biz yönetiyoruz. Faturalama TL + KDV. 0850 302 60 70 destek hattımızdan VDS tuning planlaması için bizimle iletişime geçebilirsiniz.

Performans Bottleneck'i Nasıl Bulunur? USE ve RED Metodu

Bir sunucu yavaşladığında en sık yapılan hata: tuning'e hangi katmandan başlayacağına karar vermeden config dosyalarını rastgele değiştirmektir. Önce bottleneck nerede sorusunu yanıtlayın.

Bottleneck Taksonomisi

Performans darboğazları dört ana sınıfa girer:

Tür	Belirti	Tanı Aracı
CPU bound	top'ta %us + %sy yüksek (>%80), load average CPU çekirdek sayısının üstünde	top, htop, mpstat, sar -u
I/O bound	iostat'ta %util yüksek (>%70), await ms yüksek, top'ta %wa (iowait) yüksek	iostat -x, iotop, dstat, sar -d
Memory bound	free'de cache düşük, si/so swap aktif, OOM killer log'da, vmstat'ta r run queue yüksek	free -h, vmstat 1, sar -r, /proc/meminfo
Network bound	ss -s'te yüksek TIME_WAIT, tcp retransmit, ifconfig RX/TX errors, ethtool ring buffer drop	ss, ethtool -S, sar -n DEV, mtr, iftop

Her bottleneck sınıfının kendine özgü tedavi yöntemi vardır. CPU bound bir sunucuya RAM eklemek hiçbir şey çözmez. I/O bound bir veritabanı sunucusuna CPU çekirdeği eklemek hız kazandırmaz. Doğru tanı şarttır.

USE Metodu (Utilization, Saturation, Errors)

Brendan Gregg'in geliştirdiği USE metodu, sunucu kaynaklarını sistematik olarak gözden geçirmek için kullanılır:

• Utilization — kaynak yüzde kaç meşgul? (CPU %, disk %util, RAM kullanım yüzdesi)
• Saturation — kuyruğa ne kadar iş birikmiş? (load average, run queue, I/O queue depth)
• Errors — hata sayacı yükseliyor mu? (TCP retransmit, disk I/O error, OOM kill, ECC memory error)

Her kaynak (CPU, RAM, disk, network, file descriptor) için üç soruyu da yanıtlayın. Sadece utilization değil, saturation'ı da ölçmek kritik — disk %50 doluyken bile queue depth 32'de takılıysa I/O bound demektir.

RED Metodu (Rate, Errors, Duration)

USE sunucu kaynaklarına bakar; RED ise uygulama servisine bakar:

• Rate — saniyede kaç istek? (req/s, query/s, transaction/s)
• Errors — kaçı 5xx döndü? (HTTP 500/502/503/504, SQL error, timeout)
• Duration — istek süresi dağılımı? (p50, p95, p99 latency)

Modern monitoring (Prometheus + Grafana, Netdata, dashboard tabanlı sistem izleme) USE + RED metriklerini eşzamanlı toplar. p99 latency 800 ms ise ama CPU %30'da ise sorun CPU değil; muhtemelen DB I/O veya network. Bu metodla kör tuning yapmaktan kaçınırsınız.

Hızlı Tanı Komutları (Shell)

Bir VDS sunucusunda performans sorunu olduğunda 5 dakikada çalıştırılacak komutlar:

# 1. Genel resim — load average + CPU + RAM + disk + network
top              # interaktif, q ile çık
htop             # daha güzel UI

# 2. CPU per-core breakdown
mpstat -P ALL 2 5   # 5 saniye boyunca her core'un %us %sy %wa

# 3. Disk I/O
iostat -xz 2 5      # 5 saniye boyunca disk %util, await, w/s, r/s

# 4. Memory + swap
free -h
vmstat 2 5          # r run queue, si/so swap aktivitesi

# 5. Network bağlantı durumu
ss -s               # özet: established, TIME_WAIT, FIN_WAIT
ss -tlnp            # dinleyen portlar + proces

# 6. PID-bazlı kaynak kullanımı
ps aux --sort=-%cpu | head -10
ps aux --sort=-%mem | head -10

# 7. Disk doluluk + inode
df -h
df -i

# 8. Sistem log son 100 satır
journalctl -p err -n 100
dmesg | tail -50

Bu 8 komut tipik bir bottleneck'i 5 dakikada tespit eder. Sonrasında ilgili katmana özel tuning'e geçersiniz.

Linux Kernel Sysctl Tuning

Linux kernel varsayılan parametreleri genel amaçlı yapılandırılmıştır — bir laptop ile bir web sunucusu için aynı değerleri kullanır. Web/DB sunucusunda /etc/sysctl.conf veya /etc/sysctl.d/99-buyukweb.conf dosyasına aşağıdaki ayarlar uygulanır.

Network (TCP) Tuning

# Yeni bağlantı listener queue — varsayılan 128 çok düşük
net.core.somaxconn = 1024

# Network device backlog — paket geliyor ama henüz işlenmedi
net.core.netdev_max_backlog = 10000

# SYN backlog — half-open connection queue
net.ipv4.tcp_max_syn_backlog = 8192

# TIME_WAIT durumundaki socketleri tekrar kullan
net.ipv4.tcp_tw_reuse = 1

# FIN_WAIT timeout — varsayılan 60s; 15s daha hızlı socket boşaltır
net.ipv4.tcp_fin_timeout = 15

# Outbound ephemeral port aralığı — varsayılan 32768-60999, genişlet
net.ipv4.ip_local_port_range = 10000 65535

# TCP keepalive — uzun süre boş bağlantıyı kapat
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

# Conntrack tablosu — yüksek bağlantı sayısı için artır
net.netfilter.nf_conntrack_max = 524288

# TCP congestion control — BBR (Linux 4.9+) modern yüksek-perf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# SYN flood koruması
net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_congestion_control = bbr özellikle önemli: BBR (Bottleneck Bandwidth and Round-trip propagation time) Google tarafından geliştirilen modern congestion control algoritmasıdır. Klasik CUBIC ile karşılaştırıldığında %5-15 throughput artışı ve %20-30 latency düşüşü görülür.

Memory Tuning

# Swap'a düşme eğilimi — web sunucusunda düşük tutun
vm.swappiness = 10

# DB sunucusunda swap'ı neredeyse hiç kullanma
vm.swappiness = 1

# Page cache write-back oranı
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5

# OOM killer log'da daha verbose
vm.oom_kill_allocating_task = 0

# Transparent Huge Pages — DB için "never", web için "madvise"
# /sys/kernel/mm/transparent_hugepage/enabled

vm.swappiness web sunucusunda 0 veya 1 değil 10 önerilir; sıfır yapmak OOM riskini artırır. DB sunucusunda InnoDB buffer pool'un swap'a düşmemesi için 1 değeri yerinde olur.

File Descriptor Limits

# Sistem geneli max file descriptor
fs.file-max = 2097152

# Per-process max
fs.nr_open = 1048576

# inotify watcher limit (büyük site, file change detection için)
fs.inotify.max_user_watches = 524288

Ek olarak /etc/security/limits.conf dosyasında per-user limit'leri açın:

nginx       soft    nofile  65535
nginx       hard    nofile  65535
www-data    soft    nofile  65535
www-data    hard    nofile  65535
mysql       soft    nofile  65535
mysql       hard    nofile  65535
mysql       soft    nproc   65535
mysql       hard    nproc   65535

"Too many open files" hatası genelde bu iki dosyanın tune edilmemesinden kaynaklanır. Yüksek trafikli sunucularda mutlaka ayarlanmalıdır.

Veritabanı Shared Memory (kernel.shm*)

PostgreSQL, MariaDB shared memory segmentleri kullanır. Büyük RAM sunucularda kernel limit'leri açılmalı:

kernel.shmmax = 17179869184       # 16 GB byte cinsinden
kernel.shmall = 4194304           # 16 GB / 4 KB page

Modern kernel'lerde bu değerler zaten yüksek varsayılan gelir; eski dağıtımlarda gerekebilir.

Sysctl Uygulama

Değişiklikleri kalıcı kılmak için /etc/sysctl.d/99-buyukweb.conf oluşturup içine ayarları yazın, sonra:

sudo sysctl -p /etc/sysctl.d/99-buyukweb.conf

# Doğrulama
sysctl net.core.somaxconn
sysctl vm.swappiness

Reboot sonrası ayarlar otomatik yüklenir.

CPU Governor Ayarı

Linux varsayılanda ondemand veya powersave governor kullanır — laptop için mantıklı ama 24/7 web sunucusu için performance governor önerilir. CPU frekansı sürekli max'ta tutulur, request gelince frekans yükseltme gecikmesi yaşanmaz.

# Mevcut governor kontrol
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# Performance moduna geç
sudo apt install linux-tools-common linux-tools-$(uname -r)
sudo cpupower frequency-set -g performance

# Reboot sonrası kalıcı — systemd unit ile veya /etc/rc.local

Önemli not: Performance governor güç tüketimini artırır (~%5-10). Modern VDS sağlayıcılarında bu zaten host tarafında yönetildiği için guest VM'de değiştirmek bazen mümkün olmaz. Bare-metal dedicated sunucularda etkisi belirgindir.

Disk I/O Scheduler ve NVMe Avantajı

Disk I/O scheduler, OS'un disk request'lerini hangi sırayla diske gönderdiğini belirler. Doğru scheduler seçimi, özellikle DB sunucularında belirgin fark yaratır.

Scheduler Türleri

Scheduler	Uygun Disk	Karakter
noop (legacy) / none (mq-blk)	NVMe, SSD, virtualized disk	İşletim sistemi karışmaz, disk firmware'i sırayı belirler
deadline / mq-deadline	SATA SSD, HDD	Latency-bounded, request'i belirli süre içinde teslim
cfq (legacy) / bfq	Çoklu kullanıcı HDD	Fair-queueing, her process eşit pay

NVMe SSD için none (mq-blk) önerilir; modern NVMe kontrolcüsü zaten dahili kuyruğu mükemmel yönetir. SATA SSD için mq-deadline iyi seçim. HDD üzerinde rastgele I/O ağırlıklı iş yükü için bfq.

Scheduler Değiştirme

# Mevcut scheduler kontrol
cat /sys/block/nvme0n1/queue/scheduler
# Çıktı: [none] mq-deadline kyber bfq

# none seçili — köşeli parantez içinde

# Geçici değiştir
echo none | sudo tee /sys/block/nvme0n1/queue/scheduler

# Kalıcı — /etc/udev/rules.d/60-scheduler.rules
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"

Filesystem Mount Seçenekleri

ext4 ve XFS filesystemleri varsayılan mount seçenekleri genel amaçlıdır. Web/DB sunucularda /etc/fstab dosyasında performans odaklı mount seçenekleri kullanılır:

# ext4 örnek — atime kayıt etme, commit aralığı 60 saniye
/dev/nvme0n1p1  /  ext4  noatime,nodiratime,commit=60,errors=remount-ro  0 1

# XFS örnek
/dev/nvme0n1p1  /  xfs   noatime,nodiratime,logbufs=8,logbsize=256k,allocsize=64m  0 1

noatime özellikle önemli — varsayılanda Linux her dosya okumasında "access time" yazar (write işlemi). noatime ile bu kapatılır; mail spool ve high-IOPS web içerik dizinlerinde %5-15 IOPS azalması sağlanır.

NVMe vs SATA SSD vs HDD Performans Karşılaştırma

Disk Türü	Rastgele 4K Read IOPS	Sıralı Read Throughput	Latency (avg)	Web Hizmet Etkisi
NVMe (Gen3/Gen4)	300.000-1.000.000+	3.000-7.000 MB/s	0.05-0.1 ms	DB sorgu, file I/O sıçrama hızlı
SATA SSD	80.000-100.000	500-550 MB/s	0.1-0.3 ms	DB sorgu hızlı ama NVMe altı
15K RPM SAS HDD	200-300	200-300 MB/s	2-5 ms	Veritabanı yavaş
7.2K RPM SATA HDD	100-150	100-150 MB/s	5-15 ms	Web hosting önerilmez

Buyukweb VDS sunucu paketlerinde NVMe SSD standarttır. Veritabanı ağırlıklı (WordPress + WooCommerce, dinamik dashboard, API gateway) iş yüklerinde NVMe avantajı binlerce sorgu/sn farkına dönüşür.

Web Sunucu Tuning: Apache, Nginx, LiteSpeed

Web sunucusunun kendi worker konfigürasyonu sunucunun çalıştığı RAM ve CPU çekirdek sayısına göre dikkatlice ayarlanmalıdır. Yanlış ayar swap'a düşmeye, OOM kill'e veya CPU spike'a yol açar.

Apache MPM event

Modern Apache 2.4+ için mpm_event önerilir (mpm_prefork yerine). Event multiplexing ile keepalive bağlantıları ayrı thread tutmaz, kaynak verimliği artar.

# /etc/apache2/mods-available/mpm_event.conf
<IfModule mpm_event_module>
  StartServers              4
  MinSpareThreads          50
  MaxSpareThreads         150
  ThreadLimit              64
  ThreadsPerChild          25
  MaxRequestWorkers       400      # ana parametre
  MaxConnectionsPerChild 1000      # worker recycle
</IfModule>

# KeepAlive — tutarlı bağlantı
KeepAlive On
MaxKeepAliveRequests 1000
KeepAliveTimeout 3

MaxRequestWorkers hesabı: (toplam RAM × 0.75) / ortalama PHP worker boyutu. Örneğin 4 GB RAM, 80 MB PHP worker → 3072 / 80 = 38 worker. Çok yüksek değer swap'a düşürür.

Nginx worker tuning

Nginx event-driven mimariyle düşük RAM'de yüksek concurrency sağlar.

# /etc/nginx/nginx.conf
worker_processes auto;                 # CPU core sayısına eşit
worker_rlimit_nofile 65535;            # file descriptor limit

events {
    worker_connections 4096;           # her worker kaç bağlantı
    multi_accept on;                   # birden fazla bağlantı tek seferde kabul
    use epoll;                         # Linux için optimal
}

http {
    sendfile on;                       # zero-copy file transfer
    tcp_nopush on;                     # send paketleri birlikte
    tcp_nodelay on;                    # Nagle algoritması kapalı (latency)
    keepalive_timeout 30;
    keepalive_requests 1000;

    types_hash_max_size 2048;
    server_tokens off;                 # Nginx versiyon header'da gözükmesin

    # Buffer ayarları
    client_body_buffer_size 16K;
    client_max_body_size 64m;          # upload boyutu
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;

    # Sıkıştırma
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_comp_level 6;
    gzip_types text/css application/javascript application/json text/xml application/xml image/svg+xml;

    # Brotli (modül yüklü ise)
    brotli on;
    brotli_comp_level 5;
    brotli_types text/css application/javascript application/json text/xml application/xml image/svg+xml;
}

worker_processes auto CPU çekirdek sayısına otomatik eşitlenir. worker_connections × worker_processes toplam max concurrent connection'ı verir; 8-core sunucuda 4096 × 8 = 32.768 eşzamanlı bağlantı.

LiteSpeed (Buyukweb cPanel Paketinde Hazır)

Buyukweb cPanel paketlerinde LiteSpeed Web Server önceden kurulu gelir. LiteSpeed konfigürasyon optimize edilmiş varsayılan değerlerle birlikte gelir; tipik kullanıcı manuel tuning yapmaz. WordPress üzerinde LSCache plugin'i ile sayfa düzeyinde edge cache sağlanır — TTFB tipik olarak 50-150 ms aralığına iner.

VDS üzerinde LiteSpeed Enterprise lisansı opsiyoneldir; OpenLiteSpeed (ücretsiz) versiyonu küçük ölçekte yeterli olur.

PHP-FPM Pool Tuning (Kritik)

PHP-FPM (FastCGI Process Manager) tuning, dinamik PHP siteleri için en kritik konfigürasyonlardan biridir. Yanlış değer OOM kill veya 502 Bad Gateway ile sonuçlanır.

PHP-FPM Pool Konfigürasyonu

; /etc/php/8.3/fpm/pool.d/www.conf

user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; Process manager — dynamic çoğunlukla doğru seçim
pm = dynamic

; pm.max_children = (toplam RAM × 0.6) / ortalama PHP process boyutu
; Örnek: 4 GB RAM × 0.6 = 2400 MB / 80 MB = 30
pm.max_children = 30
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 16
pm.max_requests = 500      ; memory leak prevention

; Slowlog — yavaş PHP request'lerini logla
slowlog = /var/log/php-fpm/slow.log
request_slowlog_timeout = 5s

; Process timeout
request_terminate_timeout = 120s

; Status sayfa — monitoring için
pm.status_path = /php-fpm-status
ping.path = /php-fpm-ping

pm = dynamic vs static vs ondemand

• dynamic — başlangıçta start_servers kadar process, talep arttıkça max_children'a kadar büyür, talep azalınca max_spare_servers'a düşer. Çoğu sitede en uygun.
• static — sabit max_children kadar process her zaman açık. RAM kullanımı tahmin edilebilir, ama düşük trafiğin avantajını alamaz. Çok trafikli sunucularda tercih edilebilir.
• ondemand — sadece istek geldiğinde process aç. Çok düşük bellek kullanır, ama yeni process başlatma latency'si var. Dev/test ortam ya da çok az trafikli site için.

pm.max_children Doğru Hesabı

Yanlış değer en sık karşılaşılan hatadır. Doğru hesap için:

# Ortalama PHP process boyutunu öğren
ps -ylC php-fpm8.3 --sort:rss | awk '{print \$8/1024 " MB"}'

# Sonuç: her process ~70-120 MB tipik (WordPress)

# Hesap:
# max_children = (RAM × 0.6) / avg_process_size
# 4 GB sunucu, 80 MB process → 2400 / 80 = 30
# 8 GB sunucu, 100 MB process → 4800 / 100 = 48
# 16 GB sunucu, 120 MB process → 9600 / 120 = 80

RAM'in %60'ını PHP-FPM'e bırakırız; kalan %40 OS, MariaDB, Redis, Nginx için ayrılır. RAM'in tamamını PHP-FPM'e vermek MariaDB innodb_buffer_pool'u şişirir ve kesin swap sonucu doğurur.

PHP-FPM Pool İzleme

Pool sağlığını izlemek için /php-fpm-status endpoint'ini Nginx'te aç:

location ~ ^/(php-fpm-status|php-fpm-ping)$ {
    access_log off;
    allow 127.0.0.1;
    deny all;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    include fastcgi_params;
}

curl http://localhost/php-fpm-status çağrısı active processes, idle processes, max active processes, slow requests gibi metrikleri verir. max active processes pm.max_children değerine yaklaşıyorsa pool yetersiz — değeri artırın.

OPcache + JIT (PHP 8.0+)

OPcache, PHP'nin opcode cache modülüdür. PHP dosyaları her istekte yeniden parse edilmek yerine memory'de cache'lenir. Açılmadığında PHP performansı 3-5 kat düşer.

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

opcache.enable = 1
opcache.enable_cli = 0

; Memory — büyük site için 512 MB
opcache.memory_consumption = 256

; Cache'lenebilir dosya sayısı — WordPress için 10000+
opcache.max_accelerated_files = 20000

; String buffer
opcache.interned_strings_buffer = 16

; Production'da timestamp kontrol kapalı (deploy sonrası reload)
opcache.validate_timestamps = 0

; Dev ortamında 60 saniyede bir kontrol
; opcache.revalidate_freq = 60

; Hızlı shutdown
opcache.fast_shutdown = 1

; Preload (PHP 7.4+) — boot sırasında dosyaları cache'e yükle
opcache.preload = /var/www/preload.php
opcache.preload_user = www-data

; JIT (PHP 8.0+)
opcache.jit_buffer_size = 256M
opcache.jit = tracing

opcache.validate_timestamps Tradeoff

• 0 (production) — dosya değişse de OPcache reload etmez; deploy sonrası systemctl reload php8.3-fpm zorunlu
• 1 (dev) — her revalidate_freq saniyede dosya mtime kontrol; konvansiyonel ama %5-10 perf kaybı

Production WordPress sitelerde 0 kullanın; deploy script'iniz reload'ı yapsın.

JIT (Just-In-Time Compiler) Modları

PHP 8.0 ile gelen JIT, sık çalışan opcode'ları native machine code'a derler:

• opcache.jit = tracing — modern, popüler kod yollarını compile eder
• opcache.jit = 1255 (function mode) — fonksiyon seviyesinde JIT
• opcache.jit = 0 — kapalı

WordPress gibi web siteleri için JIT etkisi sınırlıdır (%5-10 kazanım); CPU-yoğun batch işler (image processing, mathematical libraries) içinse %30-100 hızlanma görülür.

Preload (PHP 7.4+)

opcache.preload directive'i ile FPM master başlatılırken belirli PHP dosyaları kalıcı olarak OPcache'e yüklenir. Worker child'lar bu cache'i paylaşır. WordPress core dosyaları preload'a alındığında ilk request latency'si %20-30 düşer.

<?php
// /var/www/preload.php
\$wp_path = '/var/www/html';
opcache_compile_file(\$wp_path . '/wp-load.php');
opcache_compile_file(\$wp_path . '/wp-settings.php');
opcache_compile_file(\$wp_path . '/wp-includes/functions.php');
// ... diğer core dosyalar

MySQL / MariaDB my.cnf Tuning

Veritabanı tuning'i, dinamik web sitelerinde performansın en büyük tek faktörüdür. Yanlış konfigürasyon sayfayı 5x yavaşlatır.

my.cnf Temel Parametreler (16 GB RAM Örnek)

# /etc/mysql/mariadb.conf.d/99-buyukweb.cnf

[mysqld]
# InnoDB buffer pool — RAM'in %70-75'i, en kritik parametre
innodb_buffer_pool_size = 12G

# Buffer pool instances — büyük buffer için parallelism
innodb_buffer_pool_instances = 8

# Log file — transaction redo log
innodb_log_file_size = 1G
innodb_log_buffer_size = 64M

# Flush stratejisi — perf vs durability tradeoff
# 1 = strict ACID (commit her transaction'da fsync)
# 2 = commit per second (perf++, küçük data loss risk)
innodb_flush_log_at_trx_commit = 2

# I/O method — O_DIRECT NVMe'de çift cache'i (OS + DB) engeller
innodb_flush_method = O_DIRECT

# Her tablo için ayrı .ibd dosya (modern varsayılan)
innodb_file_per_table = 1

# IO capacity — NVMe için yüksek
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000

# Connection
max_connections = 200
max_connect_errors = 1000
thread_cache_size = 32

# Table cache
table_open_cache = 4000
table_definition_cache = 2000

# Query cache — MySQL 5.7+ deprecated, kapatın
query_cache_type = 0
query_cache_size = 0

# Slow query log
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

# Binary log — replication ve PITR
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
expire_logs_days = 7
max_binlog_size = 256M

# Character set
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

# Temp table
tmp_table_size = 256M
max_heap_table_size = 256M

# Sort buffer (per connection — dikkat)
sort_buffer_size = 4M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
join_buffer_size = 4M

En Kritik Üç Parametre

1. innodb_buffer_pool_size — RAM'in %70-75'i. WordPress + WooCommerce sitesinde tablolar tamamen buffer'a sığarsa sorgular RAM'den döner, NVMe bile gereksiz olur. 16 GB sunucuda 12 GB normal, 32 GB sunucuda 24 GB.

2. innodb_flush_log_at_trx_commit — 1 (kesin ACID, her commit fsync) vs 2 (perf 2-3x, son saniye data loss riski). E-commerce sitesinde 1 zorunlu olabilir; blog/CMS sitesinde 2 güvenli.

3. innodb_io_capacity — Disk IOPS'una göre ayarlanır. NVMe için 2000-5000; SATA SSD için 500-1000; HDD için 200.

MariaDB Optimizer Hint

Yavaş sorguları tespit için:

# Slow log analiz
mysqldumpslow -s t /var/log/mysql/slow.log | head -20

# pt-query-digest (Percona Toolkit)
pt-query-digest /var/log/mysql/slow.log > /tmp/digest.txt

İndex eksiklik tanısı için detaylı rehber: MySQL performans optimizasyonu.

PostgreSQL postgresql.conf Tuning

PostgreSQL kullanan müşterilerimiz için ana parametreler (16 GB RAM örnek):

# /etc/postgresql/16/main/postgresql.conf

# Buffer — RAM'in %25
shared_buffers = 4GB

# Effective cache — RAM'in %75 (OS page cache dahil tahmin)
effective_cache_size = 12GB

# Per-connection sort/hash
work_mem = 16MB

# VACUUM, CREATE INDEX gibi maintenance işlemler
maintenance_work_mem = 1GB

# WAL buffer
wal_buffers = 16MB

# Checkpoint
checkpoint_completion_target = 0.9
max_wal_size = 4GB
min_wal_size = 1GB

# NVMe disk için ayarlar
random_page_cost = 1.1            ; varsayılan 4.0 (HDD için); NVMe 1.1
effective_io_concurrency = 200    ; NVMe için yüksek

# Connection
max_connections = 200

# Logging
log_min_duration_statement = 1000   ; 1 sn üstü sorguları logla
log_checkpoints = on
log_lock_waits = on

PostgreSQL'in shared_buffers MariaDB innodb_buffer_pool_size'a karşılık gelir; ancak PostgreSQL OS page cache'e daha fazla güvenir, bu yüzden %25 yeterli olur.

Redis Tuning ve Object Cache

Redis, application-level cache için neredeyse zorunlu bir bileşendir. WordPress (Redis Object Cache plugin), Laravel, Symfony, Django, Rails session'lar, queue'lar, ratelimit Redis kullanır.

# /etc/redis/redis.conf

# Bind sadece localhost — public expose etmeyin
bind 127.0.0.1 ::1

# Max RAM — sunucunun RAM'inden ayrılan parça
maxmemory 2gb

# Eviction policy — RAM dolduğunda ne sil
maxmemory-policy allkeys-lru     ; en az kullanılanı sil

# Persistence — AOF tercih edilir
appendonly yes
appendfsync everysec              ; saniyede bir fsync, perf++

# RDB snapshot — ek backup için
save 900 1
save 300 10
save 60 10000

# Network
tcp-keepalive 60
timeout 300

# Performance
hz 100                            ; backend görevler frekansı
lazyfree-lazy-eviction yes        ; eviction async
lazyfree-lazy-expire yes          ; expire async
lazyfree-lazy-server-del yes

maxmemory-policy allkeys-lru web cache için optimal. Persistent veri için kullanılan Redis'te noeviction tercih edilir (RAM dolarsa write reddet).

WordPress + Redis Object Cache

WordPress'e Redis cache eklemek için Redis Object Cache plugin'i kurulur:

1. wp-admin → Plugins → Add New → "Redis Object Cache"
2. Activate → "Enable Object Cache" butonuna bas
3. wp-config.php içine:

   define('WP_REDIS_HOST', '127.0.0.1');
   define('WP_REDIS_PORT', 6379);
   define('WP_REDIS_PREFIX', 'siteadi:');
   define('WP_REDIS_DATABASE', 0);
   

Aktif olduktan sonra her sayfa render'ı için ~20-50 MySQL sorgusu Redis cache'e döner; TTFB tipik olarak %40-60 düşer.

Cache Stack: Çok Katmanlı Performans

Modern bir web stack'inde 6 farklı cache katmanı birlikte çalışır:

Katman	Yer	Süre	Etki
1. Browser cache	Kullanıcı tarayıcısı	Cache-Control: max-age	Tekrar ziyarette assets cache
2. CDN edge cache	Cloudflare ya da CDN provider	Edge TTL	İlk byte gecikmesi azalır, statik içerik geri
3. Reverse proxy cache	Nginx fastcgi_cache, Varnish	Konfigürasyon	Dinamik HTML cache, PHP'ye gitmez
4. Object cache	Redis (WP_Object_Cache vs.)	RAM içi	DB sorgusu RAM'den döner
5. Opcode cache	OPcache	RAM içi	PHP parse atlamak
6. DB query cache	App-level Redis (legacy query_cache yok)	RAM içi	Yavaş sorgu cache

Hepsini birlikte çalıştırmak en yüksek performans sağlar. Buyukweb cPanel paketinde LSCache + ImunifyAV + LiteSpeed kombinasyonu 1, 3, 5 katmanlarını otomatik sağlar. 4 (Redis) opsiyonel; aktif edilince e-commerce hızı belirgin artar.

Nginx fastcgi_cache (Dinamik HTML Cache)

# /etc/nginx/conf.d/fastcgi_cache.conf
fastcgi_cache_path /var/cache/nginx/fastcgi
    levels=1:2
    keys_zone=PHPCACHE:200m
    max_size=2g
    inactive=60m
    use_temp_path=off;

fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header updating http_500;
fastcgi_cache_lock on;
fastcgi_cache_min_uses 1;
fastcgi_cache_revalidate on;

# server block içinde
location ~ \.php$ {
    fastcgi_cache PHPCACHE;
    fastcgi_cache_valid 200 60m;     ; HTTP 200 cevabı 60 dakika cache
    fastcgi_cache_valid 404 10m;
    add_header X-Cache $upstream_cache_status;
    # ... diğer fastcgi_pass ayarları
}

WordPress için fastcgi_cache aktif edildiğinde PHP-FPM'e gitmeyen istek oranı %90+ olur — sunucu kapasitesi 10x artar.

HTTP/2, HTTP/3 ve QUIC

Modern HTTP protokol sürümleri TTFB'yi (Time To First Byte) ve toplam page load süresini ciddi düşürür:

• HTTP/1.1 — her resource için ayrı TCP bağlantı (browser 6 paralel limit). Header sıkıştırma yok. Tarih.
• HTTP/2 — tek TCP üzerinde multiplexing, HPACK header sıkıştırma, server push, binary frame. Modern web standardı.
• HTTP/3 — TCP yerine QUIC (UDP üzerinde). 0-RTT bağlantı kurma, connection migration (WiFi → 4G geçişte session devam), head-of-line blocking yok.

Nginx'te HTTP/2 ve HTTP/3 (QUIC)

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    # HTTP/3 / QUIC (Nginx 1.25+ dahili destekli)
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;
    add_header Alt-Svc 'h3=":443"; ma=86400';

    ssl_certificate /etc/letsencrypt/live/site/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/site/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    # ... rest of config
}

Cloudflare üzerinde HTTP/3 zaten otomatik aktif olur — origin Nginx'iniz HTTP/2 destekliyorsa Cloudflare edge'inden ziyaretçilere HTTP/3 sunulur.

Brotli vs gzip Sıkıştırma

Brotli (Google geliştirimi) gzip'e göre %15-25 ek küçültme sağlar. JS bundle'ları, CSS dosyaları için belirgin fark yaratır.

Format	Sıkıştırma Hızı	Decompression Hızı	Çıktı Boyutu	Browser Desteği
gzip -6	Hızlı	Çok hızlı	Baseline	%100
brotli -5	Orta	Hızlı	gzip'in -%15	Modern browsers (2017+)
brotli -11 (max)	Çok yavaş	Hızlı	gzip'in -%25	Modern browsers

Brotli için dinamik içerik -5 (orta seviye, CPU dostu), statik dosyalar -11 (pre-compress, build time'da) önerilir.

Buyukweb VDS Önerilen Stack

VDS sahibi müşterilerimize, yukarıdaki tüm tuning'i içeren önerilen production stack:

• OS: Ubuntu 22.04 LTS (uzun destek, geniş paket havuzu)
• Web Server: Nginx 1.25+ (HTTP/3 dahili)
• PHP: PHP 8.3 + PHP-FPM + OPcache + JIT
• Database: MariaDB 10.11 LTS (innodb_buffer_pool 70% RAM)
• Cache: Redis 7.x + Nginx fastcgi_cache
• TLS: Let's Encrypt + acme.sh
• Monitoring: Netdata (lightweight) veya Prometheus + Grafana
• Backup: Veeam günlük (Buyukweb VDS standart)
• Firewall: iptables / nftables + Fail2Ban + cloud firewall

Alternatif: OpenLiteSpeed + LSCache kombinasyonu — Nginx + fastcgi_cache yerine OpenLiteSpeed kuracaksanız LSCache plugin'i ile WordPress için 0-config edge cache çalışır. cPanel'siz VDS'te güzel alternatiftir.

Monitoring: Netdata, Prometheus + Grafana

Sunucu tuning sonrası sürekli izleme şart. Her gün sunucu metriklerine bakmadan tuning'in etkisini ölçemezsiniz.

Netdata (Hızlı Kurulum, Lightweight)

# Tek satır kurulum
bash <(curl -Ss https://my-netdata.io/kickstart.sh)

Default'ta her saniye 2000+ metrik toplar (CPU per-core, disk per-mount, network per-interface, MySQL/Redis/Nginx eklentileri otomatik bulur), web UI http://sunucu:19999 adresinden açılır. Sıfır config, dakikada kurulur. Küçük-orta VDS için ideal.

Prometheus + Grafana

Daha büyük altyapılarda Prometheus (time-series DB) + node_exporter (sunucu metrikleri) + mysqld_exporter + redis_exporter + nginx-prometheus-exporter kombinasyonu kurulur. Grafana üzerinde dashboard ile çoklu sunucu izleme yapılır. Operasyonel yük daha yüksek ama çok daha güçlü.

Kapasite Planlama: Ne Zaman VDS Büyütmeli?

Sunucunuzun yetişmediğini gösteren sinyaller:

• Load average sürekli CPU core sayısının üstünde (8 core sunucuda load > 8)
• PHP-FPM max active processes pm.max_children değerine yaklaşıyor (%80+)
• MariaDB Threads_running sürekli yüksek (20+ aktif sorgu)
• Swap kullanımı sürekli artıyor (vmstat'ta si/so non-zero)
• 502/504 hata oranı dakikada birkaç defa
• TTFB P95'i 1 saniyenin üstünde sürekli

Bu sinyaller varsa: önce tuning denenir (yukarıdaki tüm bölümler), sonuçsuzsa VDS büyütme (RAM/CPU artırım) düşünülür. Bursa Tier 3 datacenter'da VDS upgrade'i Buyukweb destek hattından 0850 302 60 70 dakikalar içinde yapılır.

Karar Matrisi: Önce Ne Tune Et?

Bottleneck'iniz tespit edildikten sonra hangi katmana yatırım yapmalı?

Bottleneck	İlk Tedavi	İkinci Tedavi
CPU bound (PHP/web yoğun)	OPcache + JIT + Nginx workers + PHP-FPM pool	CDN edge cache, kod profil
I/O bound (DB yoğun)	innodb_buffer_pool_size, slow query index, NVMe disk	Read replica, partitioning
Memory bound	Redis object cache + page cache plugin	RAM upgrade, query optimization
Network bound	TCP BBR, sysctl backlog, jumbo frame (LAN)	CDN, daha yakın datacenter
File descriptor exhaustion	nofile limit + sysctl fs.file-max	Bağlantı pool size

Sıralama önemli — pahalı ve büyük bir CPU upgrade yapmadan önce OPcache + Redis açın; tahmin edilenden çok daha büyük etki verebilir.

Sık Sorulan Sorular (SSS)

"Bu tuning'i cPanel kullanıyorum, kendim mi yapacağım?"

Buyukweb cPanel paketlerinde sunucu seviyesi tuning bizim tarafımızdan yapılır — LiteSpeed + LSCache, CloudLinux LVE, ImunifyAV, OPcache, MariaDB optimizasyonu paket altyapısında hazır gelir. Müşteri seviyesinde sadece PHP versiyon seçimi, e-posta hesabı, veritabanı oluşturma, dosya yönetimi gibi cPanel UI işlemleri var. Sysctl, my.cnf, php-fpm pool gibi alt katman ayarları cPanel sınırları içinde değiştirilemez. Bunlara erişim için VDS gerekir.

"VDS kullanmalı mıyım, paylaşımlı hosting yetmez mi?"

Cevap iş yüküne bağlı: site WordPress + WooCommerce ve günlük 5.000+ ziyaretçi alıyorsa, ya da özel kurulum (Laravel + Redis + Elasticsearch) gerekiyorsa VDS mantıklı. Standart WordPress blog (günlük < 5.000 ziyaretçi) için Buyukweb cPanel paylaşımlı paket yeterlidir ve operasyonel yük olmaz. Karşılaştırma: VDS vs paylaşımlı hosting.

"Swap eklemek hız mı azaltır mı?"

İki yüzü var. Swap yokluğu OOM kill'e yol açar — kritik bir process anında öldürülür, daha kötü senaryo. Swap varlığı swap'a düşmek hızı 100-1000x düşürür. Doğru yaklaşım: 2-4 GB swap aç, ama vm.swappiness = 1 ile çok zorunlu olmadıkça swap'a düşme. Bu şekilde OOM güvenliği var, perf cezası yok.

"innodb_buffer_pool_size'ı RAM'in tamamına versem olur mu?"

Hayır. OS, PHP-FPM, Redis, Nginx, sistem servisleri için en az %25 RAM bırakmalısınız. RAM'in tamamını DB'ye verirseniz OOM kill başlar veya swap'a düşersiniz; her iki sonuç da MariaDB'yi gerçek çıkışı yavaşlatır. Pratik formül: RAM'in %70'i DB için, %30'u OS + diğer servisler.

"OPcache JIT açmam gerek mi?"

WordPress, Laravel, Drupal gibi web framework'leri için JIT etkisi sınırlı (%5-10 kazanım). Math heavy, image processing, scientific computing PHP kodu çalıştırıyorsanız (örn. PHP ile Mandelbrot, NumPy benzeri) %30-100 hızlanma olur. WordPress için opcache.jit_buffer_size = 0 (kapalı) tamam; opcache.jit = tracing açmak da zarar vermez.

"Brotli'yi gzip yerine kullansam tam fark ne?"

JS bundle (200 KB) → gzip -6 ile 60 KB, brotli -5 ile 51 KB (%15 ek kazanım). CSS dosyası (50 KB) → gzip 12 KB, brotli 10 KB. Decompression hızı her ikisinde de hızlı. Brotli için modül kurulumu Nginx'te libnginx-mod-http-brotli-filter ve libnginx-mod-http-brotli-static paketleri yüklenir. Modern browser'lar (2017+) brotli destekler, eski browser fallback olarak gzip alır.

"VDS'imde Veeam yedek var mı? Ne sıklıkla?"

Buyukweb VDS paketlerinde Veeam günlük yedek standart hizmet kapsamındadır. Yedekler off-site storage'da tutulur ve restore self-service destek hattımızdan 0850 302 60 70 açılan ticket ile yapılır. Yedek retention politikası paket detayında belirtilir; standart politika 7-14 gün arası rolling yedek.

"TCP BBR aktif edilmeli mi, riski var mı?"

Linux 4.9+ kernel'de BBR (Bottleneck Bandwidth and Round-trip propagation time) congestion control desteklenir. CUBIC (varsayılan) ile karşılaştırıldığında %5-15 throughput artışı, %20-30 latency düşüşü ölçülür. Riski yok denecek kadar düşük — aktif etmek için /etc/sysctl.conf dosyasına net.core.default_qdisc = fq ve net.ipv4.tcp_congestion_control = bbr ekleyin, sysctl -p ile uygulayın. Modern Ubuntu/Debian/Rocky kernel'lerinde modül yüklü gelir.

Sonuç ve Sonraki Adımlar

Sunucu optimizasyonu, frontend tuning ile ayrı bir dünyadır. Web framework'ünüz Next.js ya da WordPress olsun, altta yatan Linux kernel, disk I/O scheduler, PHP-FPM pool, OPcache, MariaDB my.cnf doğru ayarlanmadıysa frontend optimizasyonun yarısı boşa gider. Önemli takeaways:

1. Bottleneck'i USE + RED metoduyla tespit edin — kör tuning yapmayın
2. Sysctl temellerini açın — somaxconn, swappiness, file-max, TCP BBR
3. NVMe için scheduler = none, ext4 noatime mount
4. PHP-FPM pool'u RAM'e göre hesaplayın — (RAM × 0.6) / process size
5. OPcache zorunlu, JIT bonus — production validate_timestamps = 0
6. MariaDB innodb_buffer_pool = RAM × 0.7 — DB perf'in tek en büyük faktörü
7. Redis object cache — TTFB %40-60 düşer
8. 6 katmanlı cache stack — browser → CDN → reverse proxy → object → opcode → query
9. HTTP/2 + HTTP/3 — TCP yerine QUIC ile 0-RTT
10. Brotli sıkıştırma — gzip'e göre %15-25 ek kazanım

Buyukweb VDS sunucu paketlerimizde root erişiminizle bu tuning'in tamamını uygulayabilirsiniz. cPanel paylaşımlı paketlerimizdeyse altyapı tarafından otomatik gelir. Bursa Tier 3 veri merkezi + NVMe SSD + Intel Xeon E5-V4 + DDoS L3/L4/L7 koruma + Veeam günlük yedek ile production-grade altyapı sunuyoruz.

---

İlgili Büyükweb Hizmetleri

• VDS Sunucu — KVM tam virtualization, root erişim, NVMe SSD, sysctl/my.cnf/PHP-FPM tuning özgürlüğü
• cPanel Web Hosting — LiteSpeed + LSCache + CloudLinux LVE hazır
• Paket Karşılaştırma — Trafik ve iş yüküne göre paket seçimi
• Hosting ve SEO İlişkisi — TTFB + CWV + datacenter etkisi
• MySQL Performans Optimizasyonu — slow query → index → cache
• Core Web Vitals 2026 — frontend tarafı metrik

VDS tuning planlaması, sunucu seviyesi optimizasyon danışmanlığı veya kapasite planlama için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz. Bursa Tier 3 veri merkezimizden Türkiye'ye yakın, KVKK uyumlu yüksek performanslı sunucu altyapısı sağlıyoruz.