Linux Sunucu Optimizasyonu: CPU, RAM, Disk ve Web Sunucusu İçin Uygulamalı Rehber

Linux sunucu optimizasyonu ölçümle başlar: top, vmstat ve iostat ile darboğazın CPU'da mı, RAM'de mi, diskte mi (iowait) yoksa ağda mı olduğu belirlenir. Ardından gereksiz servisler kapatılır, swap ve swappiness ayarlanır; web sunucusunun worker ve keepalive değerleri, PHP-FPM süreç sayısı, veritabanı buffer ayarları ve önbellek katmanı yapılandırılır. Her değişiklik tek tek yapılır ve ölçülerek doğrulanır.

Bu rehberdeki her adım aynı döngüye dayanır: önce ölçün, tek bir ayarı değiştirin, sonra aynı koşullarda yeniden ölçün. Komutlar Ubuntu/Debian ve AlmaLinux/Rocky Linux için ayrı verildi. Adımları kendiniz uygulayabilirsiniz; işi bir ekibe bırakmak isterseniz sunucu optimizasyonu hizmeti için teklif alabilirsiniz.

1. Ölçün: darboğazın CPU, RAM, disk veya ağda olduğunu belirleyin.
2. İşletim sistemi: gereksiz servisleri kapatın, swap ve dosya limitlerini düzenleyin.
3. Web sunucusu: Nginx veya Apache'nin worker ve keepalive ayarlarını yapın.
4. PHP: PHP-FPM süreç sayısını RAM'e göre hesaplayın, OPcache'i kontrol edin.
5. Veritabanı: InnoDB buffer pool'u boyutlandırın, yavaş sorguları bulun.
6. Önbellek: sayfa ve nesne önbelleği ekleyin.
7. Ağ: TCP BBR, HTTP/2 ve sıkıştırmayı etkinleştirin.

Sunucu optimizasyonu nedir, nereden başlanır?

Sunucu optimizasyonu, aynı donanımla daha fazla isteği daha kısa sürede karşılamak için işletim sistemi, web sunucusu, PHP, veritabanı ve önbellek ayarlarının iş yüküne göre düzenlenmesidir. Başlangıç noktası ayar dosyası değil, ölçümdür.

Hazır ayar listeleri belirli bir sunucu için yazılır; 16 GB'lık bir veritabanı sunucusunda işe yarayan değer, web sunucusunun da çalıştığı 4 GB'lık bir VDS'te swap'a yol açabilir. Bu yüzden her ayar için iki soru sorulur: Bu ayar neyi değiştirir, etkisini hangi metrikle görürüm?

Önce ölç: temel metrikler

Değişiklikten önce yoğun saatteki durumu kaydedin. Aşağıdaki komut grubu yük, bellek, disk ve bağlantı durumunu tarih damgalı bir dosyaya yazar. iostat, sysstat paketindedir (Ubuntu/Debian: sudo apt install sysstat, AlmaLinux/Rocky: sudo dnf install sysstat).

{ date; uptime; nproc; free -m; vmstat 1 5; iostat -xz 1 3; ss -s; } > ~/olcum-$(date +%F-%H%M).txt

vmstat ve iostat'ın ilk raporu sistem açıldığından beri geçen sürenin ortalamasıdır; anlık durumu sonraki satırlar gösterir. Aynı komutu her değişiklikten sonra benzer trafik saatinde tekrar çalıştırın.

Hedef metrikler: TTFB, p95 yanıt süresi, load average

• TTFB (Time to First Byte): isteğin gönderilmesinden yanıtın ilk baytının gelmesine kadar geçen süre. Google'ın web.dev rehberi çoğu site için 0,8 saniye veya altını hedef gösterir.
• p95 yanıt süresi: isteklerin yüzde 95'inin bu sürenin altında tamamlandığı değer. Ortalama, birkaç çok yavaş isteği gizler; p95 gizlemez.
• Load average: çalışan veya çalışmayı bekleyen süreçlerin ortalama sayısı. Linux'ta kesintisiz disk beklemesindeki (D durumu) süreçleri de içerdiği için çekirdek sayısıyla ve CPU kullanımıyla birlikte okunur.

TTFB curl ile, p95 ise istek süresini yazan bir Nginx log biçimiyle ölçülür; son iki komutu birkaç yüz istek biriktikten sonra çalıştırın:

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer} sn\n' https://alanadiniz.com/

# /etc/nginx/conf.d/zamanli-log.conf (http bağlamı)
log_format zamanli '$remote_addr $time_iso8601 "$request" $status $request_time $upstream_response_time';
access_log /var/log/nginx/zamanli.log zamanli;   # server bloğunda access_log varsa oraya ekleyin

n=$(wc -l < /var/log/nginx/zamanli.log)
awk '{print $(NF-1)}' /var/log/nginx/zamanli.log | sort -n | sed -n "$(( n * 95 / 100 ))p"

Adım 1 · Darboğazı bulun

CPU, bellek, disk ve ağa sırayla bakın; kuyruk oluşturan kaynak darboğazdır ve optimizasyon oradan başlar.

top/htop, vmstat, iostat, ss

• top/htop: CPU satırında us uygulama kodunun, sy çekirdeğin harcadığı süredir. wa (iowait) CPU'nun disk işlemini beklediği süreyi, st (steal) sanal makinenin fiziksel host tarafından bekletildiği süreyi gösterir.
• vmstat 1 5: r çalışmaya hazır süreçleri, b G/Ç bekleyen süreçleri, si/so saniyelik swap giriş ve çıkışını verir.
• iostat -xz 1 5: r_await/w_await okuma ve yazma isteklerinin milisaniye cinsinden bekleme süresidir. NVMe gibi istekleri paralel işleyen disklerde %util değerinin yüzde 100'e yaklaşması tek başına doygunluk anlamına gelmez.
• ss -s: açık TCP bağlantılarının özetidir; ani artış trafik sıçramasını veya bot trafiğini gösterebilir.

Örnek: 2 çekirdekli bir sunucuda load average 6, wa yüzde 40 ve vmstat b sütunu sürekli 3–4 ise süreçler diski bekliyordur. PHP süreç sayısını artırmak sorunu büyütür; çözüm veritabanı ve disk katmanındadır.

CPU mu, RAM mi, disk mi, ağ mı? (karar tablosu)

Adım 2 · İşletim sistemi katmanı

Amaç, belleği ve CPU'yu gerçekten kullanılan servislere bırakmak ve bellek baskısında öngörülebilir davranış sağlamaktır.

Gereksiz servisleri kapatma (systemctl)

systemctl list-units --type=service --state=running
sudo ss -tulpn                              # port dinleyen süreçler
sudo systemctl disable --now servis-adi     # yalnızca emin olduğunuz servis için

Uyarı: sshd, ağ yönetimi, güvenlik duvarı (ufw, firewalld), cron ve zaman senkronizasyonu servislerini kapatmayın; sshd'yi kapatırsanız sunucuya uzaktan erişiminizi kaybedersiniz.

Swap ve swappiness

Swap, RAM dolduğunda bellek sayfalarının taşındığı disk alanıdır. Swappiness, çekirdeğin bellek baskısında swap'a ne kadar istekli başvuracağını belirler; varsayılanı 60'tır, güncel çekirdeklerde 0–200 aralığında ayarlanır. Veritabanı ve PHP çalışan sunucularda 10 gibi düşük bir değer sık kullanılır. Önce geçici deneyin, si/so değerleri iyileşirse kalıcı yapın:

cat /proc/sys/vm/swappiness
sudo sysctl vm.swappiness=10                                          # geçici
echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system                                                  # kalıcı ayarı yükler

Swappiness'ı 0 yapmak swap'ı kapatmaz ve RAM yetersizliğini çözmez. Sürekli swap trafiği varsa bellek tüketen bileşen küçültülmeli ya da RAM artırılmalıdır. Hiç swap alanı yoksa (swapon --show boş dönüyorsa) küçük bir swap dosyası, ani bellek sıçramalarında OOM killer'ın (bellek boşaltmak için süreç sonlandıran çekirdek mekanizması) veritabanını kapatmasına karşı tampon olur.

Dosya tanıtıcı limitleri

Her açık dosya ve her ağ bağlantısı bir dosya tanıtıcısı (file descriptor) kullanır. Limit aşılınca günlüklerde Too many open files hatası görülür; bu hatayı görmediyseniz limiti artırmanız gerekmez. Kabuktaki ulimit -n değeri servislerin limiti değildir; servisin limitini süreç bilgisinden okuyup systemd ile artırın:

grep 'open files' /proc/$(pgrep -o nginx)/limits
sudo systemctl edit nginx
# Düzenleyiciye şu iki satırı ekleyin:
#   [Service]
#   LimitNOFILE=65535
sudo systemctl restart nginx

Adım 3 · Web sunucusu

Web sunucusu ayarları, aynı anda kaç bağlantının ne kadar kaynakla taşınacağını belirler; limitler dosya tanıtıcı limiti ve RAM hesaba katılarak yükseltilmelidir.

Nginx: worker_processes, worker_connections, keepalive

worker_processes auto işçi süreç sayısını çekirdek sayısına eşitler. worker_connections her işçinin aynı anda açabileceği bağlantı sayısıdır; varsayılanı 512'dir ve PHP-FPM gibi arka uçlara açılan bağlantılar da bu sayıya dahildir. keepalive_timeout boştaki istemci bağlantısının ne kadar açık tutulacağını belirler; varsayılanı 75 saniyedir.

# /etc/nginx/nginx.conf
worker_processes auto;
worker_rlimit_nofile 65535;
events {
    worker_connections 4096;
}
http {
    keepalive_timeout 30s;
    # mevcut ayarlarınız
}

sudo nginx -t && sudo systemctl reload nginx ile test edip yeniden yükleyin. worker_connections değerini büyütmek, hata günlüğünde worker_connections are not enough uyarısı varsa işe yarar; bu uyarı yoksa hız kazandırmaz.

Apache: MPM event'e geçiş

MPM (Multi-Processing Module), Apache'nin istekleri süreç ve iş parçacıklarına nasıl dağıttığını belirler. prefork her bağlantıya ayrı süreç ayırır ve bellek hızla büyür; event boştaki keepalive bağlantılarını ayrı bir dinleyici iş parçacığına devrederek daha az kaynakla daha çok bağlantı taşır. mod_php iş parçacığı güvenli olmadığı için prefork ile çalışır; event'e geçmek için PHP'nin PHP-FPM üzerinden çalışması gerekir.

# Kullanılan MPM: Ubuntu/Debian
apache2ctl -V | grep -i mpm
# Kullanılan MPM: AlmaLinux/Rocky
httpd -V | grep -i mpm

# Ubuntu/Debian'da mod_php'den PHP-FPM + event'e geçiş (PHP sürümünü uyarlayın)
sudo apt install php8.3-fpm
sudo a2dismod php8.3 mpm_prefork
sudo a2enmod mpm_event proxy_fcgi setenvif
sudo a2enconf php8.3-fpm
sudo apache2ctl configtest && sudo systemctl restart apache2

AlmaLinux/Rocky 8 ve 9'da httpd genellikle event MPM ve PHP-FPM ile gelir; /etc/httpd/conf.modules.d/00-mpm.conf dosyasından doğrulayın. Geçişi yapılandırma yedeği alıp bakım penceresinde yapın. .htaccess içinde php_value kullanan siteler PHP-FPM altında hata verir; bu ayarlar .user.ini dosyasına taşınmalıdır.

LiteSpeed notu

LiteSpeed, PHP'yi PHP-FPM yerine kendi LSAPI arayüzüyle çalıştırır; süreç limitleri LiteSpeed ayarlarından, CloudLinux ortamlarında hesap bazlı limitlerden gelir. Mantık aynıdır: süreç başına bellek ile eş zamanlı süreç sayısının çarpımı ayrılan RAM'i aşmamalıdır.

Adım 4 · PHP katmanı

Belirleyici olan, eş zamanlı PHP süreci sayısı ve derlenmiş kodun bellekte tutulmasıdır.

PHP-FPM süreç yönetimi

PHP-FPM (FastCGI Process Manager), PHP isteklerini önceden başlatılmış bir süreç havuzuyla karşılar. En kritik ayar, aynı anda çalışabilecek en fazla PHP süreci sayısı olan pm.max_children'dır:

pm.max_children ≈ PHP'ye ayrılabilecek RAM ÷ ortalama PHP-FPM süreç belleği (RSS)

RSS (Resident Set Size), bir sürecin fiziksel RAM'de kapladığı alandır. Ortalamayı yoğun saatte şöyle ölçün:

ps -o rss= -p "$(pgrep -d, -f 'php-fpm: pool')" | awk '{s+=$1; n++} END {printf "Süreç: %d, ortalama RSS: %.0f MB\n", n, s/n/1024}'

Örnek: 4 GB RAM'li bir sunucuda işletim sistemi, veritabanı ve önbelleğe 1,5 GB bırakılırsa PHP'ye yaklaşık 2.560 MB kalır. Süreç başına 60 MB ölçüldüyse 2.560 ÷ 60 ≈ 42 eder; güvenlik payıyla 40 makul bir başlangıçtır. Havuz dosyası Ubuntu/Debian'da /etc/php/8.3/fpm/pool.d/www.conf, AlmaLinux/Rocky'de /etc/php-fpm.d/www.conf yolundadır:

pm = dynamic
pm.max_children = 40
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12
pm.max_requests = 500

Değer fazla yüksekse yoğun anda RAM biter ve swap başlar; fazla düşükse istekler kuyrukta bekler ve PHP-FPM günlüğünde server reached pm.max_children setting uyarısı çıkar. Değişiklikten sonra bu uyarıyı ve si/so değerlerini izleyin.

OPcache

OPcache, PHP betiklerinin derlenmiş halini (opcode) paylaşımlı bellekte tutarak her istekte yeniden derlenmesini önler. opcache.enable varsayılan olarak açıktır ama eklentinin yüklü olması gerekir; php-fpm8.3 -m | grep -i opcache (AlmaLinux/Rocky'de php-fpm -m) ile kontrol edin. Varsayılan 128 MB bellek ve 10.000 dosya sınırı, çok eklentili CMS kurulumlarında dolabilir:

opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000

Doluluğu komut satırından değil, web üzerinden çalışan ve erişimi kısıtlanmış bir opcache_get_status() çıktısıyla görün; komut satırındaki PHP ayrı önbellek kullanır.

Adım 5 · Veritabanı

Dinamik sitelerde sayfa üretim süresinin büyük kısmı veritabanında geçer. İki konu öne çıkar: verinin bellekten mi diskten mi okunduğu ve hangi sorguların yavaş olduğu.

innodb_buffer_pool_size

InnoDB buffer pool, MySQL ve MariaDB'nin tablo ve indeks verisini bellekte tuttuğu alandır; varsayılanı 128 MB'tır. MySQL belgelerine göre yalnızca veritabanı çalışan sunucularda fiziksel belleğin yüzde 80'ine kadarı sıklıkla buffer pool'a ayrılır; web sunucusu ve PHP aynı makinedeyse pay belirgin biçimde düşük tutulmalıdır. Diskten okuma oranını şu sayaçlarla izleyin:

sudo mysql -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';"

Innodb_buffer_pool_reads (diskten okunan) değerinin Innodb_buffer_pool_read_requests (toplam okuma isteği) değerine oranı ne kadar küçükse veri o kadar bellekten geliyordur. Ayarı Ubuntu/Debian'da /etc/mysql/conf.d/, AlmaLinux/Rocky'de /etc/my.cnf.d/ altındaki ayrı bir .cnf dosyasına mysqld bölümü altında yazın ve SELECT @@innodb_buffer_pool_size; ile uygulandığını doğrulayın; başka bir dosyadaki aynı satır sizinkini ezebilir. MySQL 8.0 ile query cache kaldırıldı; eski rehberlerdeki query_cache_size satırı MySQL 8'de sunucunun açılmasını engeller.

Yavaş sorgu günlüğü

Yavaş sorgu günlüğü (slow query log), belirlenen süreden uzun süren sorguları kaydeder. Varsayılan olarak kapalıdır ve long_query_time eşiği 10 saniyedir; web uygulamaları için 1 saniye daha anlamlı bir başlangıçtır:

sudo mysql -e "SET GLOBAL slow_query_log = 1; SET GLOBAL long_query_time = 1;"
sudo mysql -e "SHOW VARIABLES LIKE 'slow_query_log_file';"

SET GLOBAL ile değiştirilen eşik yeni bağlantılara uygulanır. Birkaç saatlik trafikten sonra günlüğü mysqldumpslow veya pt-query-digest ile özetleyin. Toplam süreye en çok katkı yapan birkaç sorguya eksik indeksi eklemek, çoğu zaman bellek ayarlarından daha büyük fark yaratır.

Paketlere göre genel başlangıç değerleri

Aşağıdaki tablo, web sunucusu, PHP ve veritabanının aynı VDS'te çalıştığı bir PHP sitesi için genel başlangıç değerleridir; kendi ölçümünüzle ayarlayın. Test sonucu değildir; RAM ve çekirdek sayıları Bulutzone TR Cloud paketlerinden alınıp yukarıdaki formüllerle hesaplanmıştır.

pm.max_children sütunu bellek açısından üst sınırdır. PHP istekleriniz ağırlıklı olarak CPU harcıyorsa yoğun anda load average çekirdek sayısını sürekli aşar; bu durumda değeri düşürmek, tüm isteklerin CPU'yu paylaşırken birlikte yavaşlamasını önler.

Adım 6 · Önbellek katmanları

En hızlı istek, PHP'ye ve veritabanına hiç ulaşmayan istektir. Dinamik sitelerin çoğunda önbellek katmanı eklemek TTFB'yi tek tek ayar değişikliklerinden daha çok etkiler.

Sayfa önbelleği

Sayfa önbelleği, üretilmiş HTML'i saklayıp aynı sayfayı PHP'yi çalıştırmadan sunar; Nginx'te fastcgi_cache, LiteSpeed'de sunucu önbelleği, WordPress gibi sistemlerde eklentilerle kurulur. Oturum açmış kullanıcılar, sepet ve ödeme sayfaları önbellek dışında tutulmalıdır; aksi halde bir kullanıcının içeriği başkasına görünebilir. Etkiyi art arda TTFB ölçümüyle görün:

for i in 1 2 3; do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://alanadiniz.com/; done

Nesne önbelleği (Redis)

Nesne önbelleği, sorgu sonuçlarını ve uygulama nesnelerini bellekte tutar; sayfa önbelleğinin kullanılamadığı oturum açmış kullanıcı ve sepet sayfalarında veritabanı yükünü azaltır. Redis 64 bit sistemlerde varsayılan olarak bellek sınırı olmadan çalışır; önbellek kullanımında redis.conf içinde sınır ve tahliye politikası belirleyin:

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli info stats çıktısında keyspace_hits ve keyspace_misses ile isabet oranını izleyin. İsabet düşük ve evicted_keys hızla artıyorsa bellek sınırı küçük kalmıştır.

Adım 7 · Ağ

Ağ ayarları en çok uzak kullanıcılarda ve büyük dosya aktarımlarında fark yaratır; bu yüzden en sona kalır.

TCP BBR

BBR, Google'ın geliştirdiği bir TCP tıkanıklık kontrol algoritmasıdır. Paket kaybını değil, ölçtüğü bant genişliğini ve gidiş-dönüş süresini esas aldığı için kayıplı ve uzun mesafeli bağlantılarda aktarım hızını artırabilir. Linux 4.9 ve sonrası çekirdek gerektirir; Ubuntu 22.04/24.04 ve AlmaLinux/Rocky 8-9 çekirdekleri bu koşulu karşılar.

uname -r
sysctl net.ipv4.tcp_available_congestion_control    # listede bbr var mı?
sudo modprobe tcp_bbr                                # yoksa modülü yükleyin
echo tcp_bbr | sudo tee /etc/modules-load.d/bbr.conf
printf 'net.core.default_qdisc = fq\nnet.ipv4.tcp_congestion_control = bbr\n' | sudo tee /etc/sysctl.d/90-bbr.conf
sudo sysctl --system

fq kuyruk disiplini 4.13 öncesi çekirdeklerde zorunluydu, yenilerinde önerilir. Etkiyi, uzak bir konumdan aynı büyük dosyayı indirirken curl -o /dev/null -s -w '%{speed_download}\n' çıktısını karşılaştırarak görün.

HTTP/2 ve sıkıştırma

HTTP/2, birden fazla isteği tek bağlantı üzerinden paralel taşır. Nginx 1.25.1 ve sonrasında http2 on; yönergesiyle, eski sürümlerde listen 443 ssl http2; satırıyla açılır. HTML, CSS, JavaScript, JSON ve SVG gibi metin yanıtlarında gzip, aktarılan veriyi azaltır:

server {
    listen 443 ssl;
    http2 on;          # Nginx 1.25.1 ve sonrası
}
# http bağlamında
gzip on;
gzip_comp_level 5;
gzip_types text/css application/javascript application/json image/svg+xml text/plain;

curl -s -o /dev/null -w '%{http_version}\n' https://alanadiniz.com/ komutu 2 döndürmelidir.

Değişiklikleri doğrulama: önce/sonra ölçümü

Bir ayarın işe yarayıp yaramadığını yalnızca aynı koşullarda tekrarlanan ölçüm gösterir:

1. Dosyanın yedeğini alın: sudo cp -a /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak-$(date +%F).
2. Temel ölçümü kaydedin: TTFB, p95, load average, si/so, disk bekleme süresi.
3. Tek bir ayarı değiştirin, sözdizimini test edin (nginx -t, php-fpm8.3 -t veya AlmaLinux/Rocky'de php-fpm -t), servisi yeniden yükleyin.
4. En az bir yoğun dönem bekleyip aynı ölçümü tekrarlayın.
5. Sonuç iyiyse koruyun, kötüyse yedeği geri yükleyin; değişikliği tarih, eski ve yeni değerle not edin.

Aynı anda birden fazla ayarı değiştirirseniz hangisinin fark yarattığını ayırt edemezsiniz. ab -n 500 -c 20 gibi yapay yük testlerini yalnızca kendi sitenizde ve sakin saatlerde çalıştırın; test de sunucuyu yükler.

Sık sorulan sorular

Optimizasyondan sonra ne kadar hızlanma beklenir?

Evrensel bir oran yoktur; kazanç darboğazın yerine bağlıdır. Önbelleksiz bir sitede sayfa önbelleği TTFB'yi belirgin biçimde düşürebilirken, zaten önbellekli bir sitede worker ayarları ölçülebilir fark yaratmayabilir. Beklentiyi temel ölçümünüzle kıyaslanan sayılara dayandırın.

Önce hangi ayar değiştirilmeli?

Ölçümde doygun görünen kaynağa ait ayar. Net bir darboğaz yoksa düşük riskli iki adımla başlayın: yavaş sorgu günlüğünü açmak ve sayfa önbelleği kurmak.

Linux sunucu neden yavaşlar?

En yaygın nedenler RAM yetmediği için başlayan swap kullanımı, indekssiz veya ağır veritabanı sorguları, önbelleksiz PHP uygulamaları, bot kaynaklı ani trafik ve sanal sunucularda fiziksel host'taki kaynak çekişmesidir (st). Hangisinin geçerli olduğunu Adım 1'deki karar tablosu ayırır.

Ne zaman donanım yükseltmesi gerekir?

Optimizasyondan sonra normal trafik altında bir kaynak hâlâ doygun kalıyorsa yükseltme zamanı gelmiştir; ayarlar kaynak eksikliğini ancak belli bir noktaya kadar telafi eder.

• RAM: buffer pool ve PHP-FPM havuzu makul değerlere indirildiği halde yoğun saatte swap trafiği sürüyorsa.
• CPU: sayfa önbelleği ve OPcache devredeyken load average çekirdek sayısını sürekli aşıyor ve us yüksek kalıyorsa.
• Disk: yavaş sorgular giderildiği ve buffer pool büyütüldüğü halde r_await/w_await yüksek kalıyorsa.

Örneğin 4 GB RAM'li TR Cloud v2'den 8 GB RAM'li TR Cloud v4'e geçmek, tablodaki gibi hem buffer pool'a hem PHP havuzuna yer açar. Paket ayrıntıları VDS sanal sunucu sayfasındadır.

Bu adımları kendiniz uygulayabilirsiniz. Optimizasyonu bir ekibe bırakmak isterseniz tek seferlik sunucu optimizasyonu hizmeti için teklif isteyebilirsiniz. Sonrasında sunucunun ve servislerin sürekli izlenmesini istiyorsanız, sunucu izleme ve servis kontrolü içeren SLA'lı sunucu yönetimi paketlerine bakabilirsiniz; iki model arasındaki farkı managed server rehberimizde anlattık.

Kaynaklar

• Linux Kernel Documentation: /proc/sys/vm (swappiness)
• nginx: Core functionality
• nginx: ngx_http_v2_module
• Apache HTTP Server 2.4: event MPM
• PHP Manual: FPM configuration
• PHP Manual: OPcache runtime configuration
• MySQL 8.4 Reference Manual: InnoDB Buffer Pool
• MariaDB Documentation: InnoDB Buffer Pool
• Redis Documentation: Key eviction
• Google BBR: Quick-Start
• web.dev: Time to First Byte (TTFB)