Sanal Sunucularda Optimizasyon Nasıl Yapılır?

Sanal Sunucularda Optimizasyon, rastgele ayar değiştirmekten çok dar boğazı bulup en çok yük bindiren katmanı hafifletme işidir. Küçük bir VPS’te hız sorunu çoğu zaman tek bir noktadan gelmez; CPU yetmez, bellek taşar, disk gecikir, PHP-FPM fazla işçi açar, veritabanı gereğinden çok sorgu taşır ya da sayfa tarafında gereksiz görsel ve komut dosyaları çalışır. Bu yüzden işe önce ölçümle başlamak gerekir: yük altında CPU, RAM, disk bekleme süresi, TTFB ve hata kayıtları görülmeden yapılan her değişiklik tahmin olur. Doğru sıra, önce temel kaynak sınırlarını netleştirmek, sonra web sunucusu, PHP, önbellek, veritabanı ve CDN/görsel katmanını tek tek iyileştirmektir. Böyle yaklaşınca hem hız artışı daha tutarlı olur hem de bir ayarın başka bir sorunu büyütüp büyütmediği kolay anlaşılır. Aynı disiplin geri alma açısından da güvenlidir: hangi değişikliğin ne etkilediği net kalır.

Sanal Sunucularda Optimizasyon için ilk bakılacak katmanlar

Önce hangi katmanın yavaşlattığını ayırın. Yük yüksekken CPU doluyorsa problem kod veya işlem sayısı olabilir; RAM doluyorsa süreç sayısı, cache boyutu veya veritabanı belleği; disk beklemesi yükseliyorsa log, sorgu veya depolama tarafı öne çıkar. TTFB yüksek ama sunucu sakin görünüyorsa uygulama katmanı veya upstream servis gecikmesi düşünülür. Bu ayrım olmadan cache eklemek de, PHP işçisini artırmak da rastgele olur.

Ölçmeden ayarlamayın: başlangıç tabanı

İlk değişiklikten önce aynı test sayfasını, aynı tarayıcıyı ve mümkünse aynı zaman aralığını kullanın. Aksi halde iyileşme mi oldu, yoksa trafik mi düştü anlaşılmaz. Basit bir komut seti çoğu küçük VPS için yeterlidir; yalnız iostat her sistemde hazır gelmez ve bazı dağıtımlarda sysstat paketi gerekir.

top
free -h
vmstat 1
iostat -x 1

Bu çıktılarda özellikle dört işaret önemlidir: sürekli yükselen load average, düşük available bellek, artan swap ve yüksek iowait. Bunlardan biri öne çıkıyorsa optimizasyon yönü de değişir. CPU dolu ama disk sakin ise önce süreç sayısı ve uygulama kodu düşünülür; RAM baskısı varsa işçi sayısı ve cache boyutu küçültülür; iowait yükseliyorsa depolama, sorgu ve log yazımı incelenir. Ölçüm yapmadan atılan her adım, sonraki düzeltmeyi daha zor hale getirebilir.

• Load average çekirdek sayısının üstüne uzun süre çıkıyorsa işlem sırası şişmiş olabilir.
• Available bellek hızla düşüyor ve swap artıyorsa aynı anda fazla süreç çalışıyor olabilir.
• iowait yüksekse disk veya veritabanı bekleme yaratıyor olabilir.
• Hata logunda 502, 504 ya da timeout görüyorsanız upstream ve worker sınırı kontrol edilmelidir.
• TTFB iyileştiği halde LCP kötü kalıyorsa sorun büyük olasılıkla istemci tarafındadır.

İşletim sistemi ve disk katmanındaki kolay kazanımlar

VPS’in altında paylaşımlı disk veya sınırlı CPU varsa küçük kazanımların bile etkisi olur. Gereksiz servisleri kapatmak, arka plandaki yedekleme ve görsel dönüştürme işleri yoğun saat dışına almak, log boyutlarını yönetmek ve disk doluluğunu kontrol altında tutmak çoğu projede ücretsiz hız kazandırır. Swap’ı tamamen kapatmak ise her sistemde doğru değildir; asıl hedef, swap’a sürekli düşen bir yapı kurmamak ve bellek baskısını görünür kılmaktır.

• Aktif olmayan cron, backup ve medya işlerini aynı saate yığmayın.
• Log dosyalarının kontrolsüz büyümesine izin vermeyin; döngüsel loglama ve arşivleme kullanın.
• Disk alanı kritik seviyeye gelmeden temizlik yapın; dolu disk performansı ve bakım süreçlerini bozar.
• Bir işlem yoğun şekilde yazma yapıyorsa aynı anda önbellek temizliği veya büyük bir yedeklemeyi çalıştırmayın.
• İşletim sistemi güncellemelerini ertelemek yerine düzenli pencereyle uygulayın; güvenlik ve performans birlikte düşünülmelidir.

Küçük bir VPS’te iyi sonuç veren yaklaşım, çok sayıda ince ayar yerine yoğun işi ayırmaktır. Örneğin gece çalışan yedekleme ile gündüz gelen ziyaretçi trafiği aynı kaynağı paylaşırsa hız dalgalanması normaldir. Böyle durumlarda çözüm yalnız cache değildir; iş zamanlaması ve I/O düzeni de aynı derecede önemlidir.

Web sunucusu, PHP ve önbellek aynı anda düşünülmeli

Nginx ya da Apache tarafında tek başına mucize yok; PHP-FPM, OPcache ve uygulama önbelleği birlikte çalışır. Önce web sunucusunun yapılandırmasını test edin, sonra PHP tarafında işçi sayısını RAM’e göre ölçün, ardından opcode cache ve sayfa veya object cache katmanlarını ekleyin. Servis adı dağıtıma göre değişir; önce gerçek adını bulmak daha güvenlidir.

systemctl list-units 'php*-fpm.service'
nginx -t
apachectl configtest

Liste sonucu size gerçek servis adını verir; bazı sunucularda php8.2-fpm, bazılarında php-fpm görünür. Doğru adı doğrulamadan reload yapmak küçük gibi görünen ama gereksiz risk taşıyan bir hatadır. Yapılandırma testi temiz geçmiyorsa bir sonraki adım reload değil, hatalı satırı düzeltmek olmalıdır.

pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 300

opcache.enable = 1
opcache.memory_consumption = 128
opcache.max_accelerated_files = 10000

Bu blok doğrudan kopyalanacak nihai değer değil, başlangıç referansıdır. pm.max_children değerini körlemesine büyütmek en sık hatalardan biridir; her ek işçi RAM tüketir ve bellek baskısı arttığında sistemin geneli yavaşlar. OPcache açık değilse PHP kodu her istekte yeniden derlenir; bu da özellikle çok sayfalı ve sık kullanılan sitelerde gereksiz yük üretir. Page cache anonim ziyaretçiler için çok etkili olabilir, ama giriş yapılmış alanlar, sepet, yönetim ekranı ve kişiselleşmiş içeriklerde dikkatli kural gerekir. Object cache için Redis veya Memcached düşünülüyorsa önce uygulamanın gerçekten bu katmandan fayda görüp görmediği ölçülmelidir.

• OPcache: PHP kodunun tekrar derlenmesini azaltır.
• Object cache: sık kullanılan sorgu sonuçlarını hafifletir.
• Page cache: anonim trafik için hızlıdır; oturumlu alanlarda istisna gerekir.
• CDN cache: statik dosyaları kullanıcıya daha yakın noktadan sunar.

Veritabanı ve depolama dar boğazını görünür hale getirin

Sadece önbelleğe güvenmek, yavaş sorguyu saklar ama çözmez. Sık çalışan sorguları EXPLAIN ile incelemek, eksik indeksleri tamamlamak, uzun süren işlemleri görmek için slow query log açmak ve yoğun yazma yapan cron işlerini ayırmak gerekir. Veritabanı RAM’e sığıyorsa küçük bir önbellek kazanımı olur; sığmıyorsa daha büyük buffer ayarı değil, sorgu düzeni ve veri modeli daha fazla fayda verir.

SHOW FULL PROCESSLIST;

Bu çıktıdan özellikle uzun süredir çalışan, kilitlenen veya sürekli aynı tabloda dönen işlemleri ayıklayın. Locked, Sending data ya da benzeri durumlar tek başına kesin hüküm değildir; yine de aynı sorgunun defalarca uzadığını gösteriyorsa inceleme gerekebilir. EXPLAIN ise hangi tablonun tam tarandığını, hangi indeksin kullanılmadığını ve sıralama maliyetinin nerede büyüdüğünü gösterir. Veritabanına daha büyük bellek ayırmak, problem sorgu kaynaklıysa yalnızca geçici rahatlama sağlar.

Depolama tarafında özellikle yazma yoğun sistemlerde gecikme görünmeden de sorun olabilir. SSD veya NVMe olması tek başına yeterli değildir; IOPS sınırı, disk doluluğu ve aynı anda çalışan başka iş yükleri sonucu değiştirebilir. Gün içinde hız düşüyorsa, çoğu zaman yedekleme, büyük rapor işleri veya medya işleme ile çakışma vardır.

CDN, sıkıştırma ve görsel yük

Sunucu iyi ayarlanmış olsa bile büyük görseller ve ağır JS paketleri kullanıcı tarafını yorar. Brotli veya Gzip sıkıştırma, HTTP/2 ya da uygun altyapıda HTTP/3, cache header’ları, görüntüleri WebP veya AVIF’e dönüştürmek ve sayfanın altında kalan görselleri tembel yüklemek çoğu projede hızlı kazanım sağlar. CDN, özellikle farklı coğrafyalardaki kullanıcılar için ağ gecikmesini düşürür; fakat oturum açmış, kişiselleşmiş ya da sık değişen içeriklerde kural dışı bırakma gerekebilir.

• Statik görseller, fontlar ve CSS/JS dosyaları CDN için uygundur.
• Admin paneli, sepet, ödeme ve kişisel sayfalar dikkatli istisna ister.
• TTFB düşük ama LCP yüksekse çoğu zaman frontend yükü baskındır.
• Dosya boyutunu küçültmeden yalnızca CDN eklemek sınırlı etki verir.

Burada kritik karar, sunucu tarafı problemi ile istemci tarafı problemi arasındaki ayrımdır. TTFB düştüğü halde sayfa ekranda geç görünüyorsa asıl iş görsel optimizasyonu, render-blocking CSS/JS azaltımı ve font yükünü kısma olur. Önce ölçün, sonra tek bir değişiklik yapın, ardından aynı test sayfasında tekrar bakın. Eğer sayfa anonim trafiğe açık ise page cache daha yüksek etki verir; üyelik, oturum ve yönetim ekranlarında ise cache kuralları yanlışsa hız yerine veri tutarsızlığı üretebilir. Bu yüzden cache politikası değişirken hangi URL’lerin hariç tutulduğunu not etmek gerekir.

Sayfa tarafında hızlı kazanım alanları

• Görselleri gerçek görüntü boyutuna indirin; tarayıcının küçülterek göstermesine bırakmayın.
• İlk ekranda gerekmeyen JS dosyalarını erteleyin; kritik olmayanlar için defer veya async düşünün.
• Font sayısını azaltın, kullanılmayan ağırlıkları temizleyin ve font-display: swap yaklaşımını değerlendirin.
• Üçüncü taraf izleme, sohbet ve widget bileşenlerini gerçekten gerekli değilse azaltın.
• Tek sayfada hem ağır görsel hem büyük tablo hem de çok sayıda reklam benzeri bileşen varsa, iyileşme önce yükten, sonra cache’den gelir.

Küçük VPS için öncelik sırası

1. Önce CPU, RAM, iowait ve TTFB tabanını ölçün.
2. Sonra PHP-FPM işçi sayısını ve OPcache durumunu düzenleyin.
3. Ardından yavaş sorguları ve indeks eksiklerini görünür hale getirin.
4. Uygunsa page cache ve object cache katmanını ekleyin.
5. Son aşamada CDN, sıkıştırma ve görsel yük hafifletmeyi tamamlayın.

Bu sıra, bütçesi sınırlı sistemlerde en çok etkiyi veren yolu öne çıkarır. CPU ve RAM baskısı düzelmeden CDN eklemek sınırlı sonuç verebilir; aynı şekilde yavaş sorguyu gizlemek, veritabanı dar boğazını ortadan kaldırmaz. Site çok küçükse ve güncelleme azsa page cache ve görsel optimizasyonu genelde en hızlı hissedilen iyileşme olur. İş yükü dinamikse PHP-FPM ve sorgu katmanı daha önemli hale gelir.

Canlıya aldıktan sonra kısa kontrol

• Aynı test sayfasında TTFB’yi yeniden ölçün ve önceki değerle karşılaştırın.
• CPU, available bellek, swap ve iowait değerlerinin yeni dengeye oturup oturmadığına bakın.
• Web sunucusu ve PHP-FPM yapılandırma testlerinin temiz geçtiğini doğrulayın.
• 502, 504, timeout veya artan PHP hatası olup olmadığını loglardan izleyin.
• Cache sonrası oturum, giriş, sepet veya yönetim ekranlarının doğru çalıştığını kontrol edin.

Eğer yeni ayardan sonra swap kullanımı artmış, hata logu kalınlaşmış ya da yanıt süresi bazı saatlerde daha da bozulmuşsa son değişikliği geri alın. Tek bir satırı geri çekip yeniden ölçmek, dört farklı ayarı aynı anda düzeltmeye çalışmaktan daha güvenlidir. İyileşme görüyorsanız da değeri hemen büyütmeyin; küçük adımlarla ilerlemek, VPS ortamında kararlılığı korur.