Hosting Seçimi Site Hızını Nasıl Etkiler

Hosting seçimi site hızını, çoğu insanın sandığından hem daha çok hem de daha az etkiler. Daha çok etkiler, çünkü sunucu tarafında kaybedilen her yüz milisaniye tarayıcı tarafında telafi edilemez; ne kadar görsel sıkıştırırsan sıkıştır, sunucu sayfayı 1,5 saniyede üretiyorsa ziyaretçin 1,5 saniye bekler. Daha az etkiler, çünkü bir sitenin toplam yükleme süresinin çoğu genellikle ön uçta geçer ve sunucuyu yükseltmek kötü yazılmış bir temayı iyileştirmez.

Bu yazıda hosting katmanının hızı tam olarak nerelerde belirlediğini anlatacağım: CPU, bellek, disk ve ağ olmak üzere dört fiziksel kaynak, bunların üstündeki yazılım yığını (PHP sürümü, opcode önbelleği, web sunucusu) ve son olarak sunucunun coğrafi konumu. Her başlıkta neyi nasıl ölçeceğini, hangi eşiğin altında sorun olduğunu ve paket değiştirmenin gerçekten çözüm olup olmadığını nasıl anlayacağını göstereceğim.

Sunucunun Hıza Katkısı Tam Olarak Nerede Başlar#

Bir sayfa isteğinin ömrünü ikiye ayır: sunucunun yanıtı üretme süresi ve tarayıcının o yanıtı çizme süresi. Hosting yalnızca birinciyi etkiler ve bu sürenin adı TTFB'dir (ilk bayta kadar geçen süre). TTFB'nin içinde de üç parça vardır: ağ gidiş-dönüşü, TLS el sıkışması ve sunucunun sayfayı üretmesi. İlk ikisi büyük ölçüde konumla, üçüncüsü kaynaklarla ilgilidir.

Bu ayrımı yapmadan "hostingim yavaş" demek yanıltıcıdır. Aşağıdaki komut üç parçayı ayrı ayrı gösterir ve teşhisin ilk adımıdır:

# Sunucu tarafını üç parçaya ayır
curl -s -o /dev/null -w \
"dns:%{time_namelookup}  tcp:%{time_connect}  tls:%{time_appconnect}  ttfb:%{time_starttransfer}\n" \
  https://firmaniz.com/

# Örnek çıktı:
# dns:0.019  tcp:0.052  tls:0.121  ttfb:0.940

Bu çıktıda ttfb eksi tls farkı, yani 0,940 - 0,121 = 0,819 saniye, tamamen sunucunun sayfayı üretmek için harcadığı süredir. Burası hostingin sorumluluk alanıdır. tls değeri yüksekse (örneğin 0,4 saniye) sorun kaynakta değil mesafededir. dns yüksekse sorun ne sunucunda ne mesafede, DNS sağlayıcındadır.

Bu tabloyu bir kez uygularsan, hosting değiştirmenin sana ne kazandıracağını önceden hesaplayabilirsin. Sayfa üretimi 800 milisaniyeyse ve toplam yükleme 4 saniyeyse, mükemmel bir sunucuya geçmek toplam süreyi en iyi ihtimalle 3,2 saniyeye indirir; kalan 3,2 saniye ön uçtadır ve paket değişikliğiyle çözülmez.

CPU: Sayfa Üretiminin Motoru#

Dinamik bir sitede sayfa üretiminin büyük kısmı işlemci işidir. PHP kodu çalışır, şablon derlenir, veriler biçimlendirilir. Bu işin süresi doğrudan çekirdek hızıyla ve sana ayrılan çekirdek payıyla orantılıdır.

Paylaşımlı paketlerde CPU genellikle bir yüzde ya da "çekirdek eşdeğeri" olarak sınırlandırılır. Bu sınıra dayandığında sunucu seni yavaşlatır (throttling) ve sayfa üretim süresi birkaç kat artar. Sinsi tarafı şudur: sınır aşımı süreklidir ama görünürde bir hata yoktur, site sadece "bazen yavaş"tır. Belirtileri tanımak için CPU limiti aşımı kaynaklı yavaşlama yazısına bakabilirsin.

Kendi sunucun varsa mevcut CPU baskısını doğrudan ölçebilirsin. En değerli tek gösterge, yük ortalamasının çekirdek sayısına oranıdır:

# Çekirdek sayısı ve anlık yük ortalaması
nproc
uptime
# Örnek: 4 çekirdek, "load average: 3.80, 3.55, 3.20"
# 3.80 / 4 = 0.95 -> doyuma çok yakın

# Kimin yediğini gör (CPU'ya göre sıralı ilk 10 süreç)
ps -eo pcpu,pmem,comm --sort=-pcpu | head -11

# Kısa süreli örnekleme: iowait ve steal sütunlarına dikkat
vmstat 1 5

vmstat çıktısındaki iki sütun özellikle önemlidir. wa (iowait) yüksekse CPU aslında boştur, diski bekliyordur; sorun işlemcide değil disktedir. st (steal) sütunu sanallaştırılmış bir sunucuda sıfırdan belirgin biçimde büyükse, fiziksel makinedeki komşuların senin CPU zamanını yiyor demektir — bu, aşırı satılmış (oversold) bir sanal sunucunun en net kanıtıdır ve kendi tarafında düzeltemezsin.

CPU ihtiyacını azaltmanın en ucuz yolu, sayfaları her istekte yeniden üretmemektir. Tam sayfa önbelleği devredeyken sunucu PHP'yi hiç çalıştırmaz; bu, çoğu sitede CPU yükünü onda birine indirir. Yani "CPU yetmiyor" dediğin noktada ilk yapılacak iş paket yükseltmek değil, önbelleği doğru kurmaktır.

Bellek: Eşzamanlı Ziyaretçinin Tavanı#

Bellek hızı değil, kapasiteyi belirler. Bir PHP işlemi ortalama 60-120 MB kullanır; kullanılabilir belleğini bu sayıya bölersen aynı anda kaç isteği işleyebileceğini bulursun. Bu tavana ulaştığında yeni istekler kuyruğa girer ve TTFB doğrusal olarak değil, aniden tavan yapar. Ziyaretçinin gördüğü şey, "site akşam 8'de çöküyor"dur.

Mevcut durumu görmek için:

# Gerçek boş bellek: "available" sütununa bak, "free" değil
free -m

# Bir PHP-FPM işleminin ortalama gerçek bellek kullanımı (MB)
ps -ylC php-fpm --sort:rss | awk '{sum+=$8; n++} END {print sum/n/1024 " MB"}'

free -m çıktısında free sütunu neredeyse her zaman düşüktür çünkü Linux boş belleği disk önbelleği olarak kullanır; bu iyi bir şeydir. Bakman gereken sütun available'dır. Bu değer toplam belleğin yüzde 10'unun altına inmişse gerçek bir sıkıntı var demektir.

Bellek tükendiğinde sistem takas alanına (swap) düşer ve bu noktada performans birkaç kat değil, on kat kötüleşir; çünkü bellek erişimi disk erişimine dönüşür. Bu mekanizmanın ayrıntısını ve doğru swap ayarlarını RAM yetersizliği ve swap etkisi yazısında ele aldım.

Paylaşımlı pakette bellek sınırını genellikle doğrudan göremezsin ama belirtisi tanıdıktır: yoğun saatte "503" ya da "Resource limit reached" sayfaları. Bu, bellek ya da eşzamanlı işlem sınırına çarptığının işaretidir.

Disk: NVMe, SATA ve Gerçek Fark#

Disk, dinamik sitelerde tahmin edilenden çok daha belirleyicidir çünkü hem uygulama dosyaları hem veritabanı hem de oturum verisi diskten okunur. Kritik olan ölçüt aktarım hızı (MB/s) değil, gecikme ve saniyedeki işlem sayısıdır (IOPS). Bir sayfa yüklemesi yüzlerce küçük dosya okuması yapar; burada önemli olan her okumanın kaç mikrosaniyede döndüğüdür.

Basit bir gecikme testi çoğu zaman yeterlidir:

# Küçük ve senkron yazma gecikmesi: veritabanı davranışına yakın profil
dd if=/dev/zero of=/tmp/test.bin bs=4k count=2000 oflag=dsync
# NVMe'de tipik olarak birkaç saniye, yavaş SATA'da onlarca saniye sürer

rm -f /tmp/test.bin

# Anlık disk baskısı: %util 90 üstüyse disk doymuş demektir
iostat -xz 1 5

iostat çıktısında %util sütunu diskin ne kadar meşgul olduğunu, await sütunu ise ortalama bekleme süresini gösterir. await değeri milisaniyelerce yüksekse istekler diskte kuyruğa giriyordur ve sitenin yavaşlığının sebebi budur. Bu teşhisin ayrıntısı disk I/O darboğazı tespiti yazısında; NVMe ile SATA SSD arasındaki farkın gerçekte ne kadar olduğunu ise NVMe ve SATA SSD hız farkı yazısında ölçümlerle karşılaştırdım.

Pratik kural şudur: statik ağırlıklı bir tanıtım sitesinde disk türü neredeyse hiç fark etmez, çünkü dosyalar zaten bellek önbelleğindedir. Veritabanı yoğun bir mağazada ya da forumda ise NVMe ile SATA arasındaki fark doğrudan sayfa süresine yansır.

Ağ ve Konum: Mesafenin Bedeli#

Işık hızı bir sınırdır ve bunu hiçbir optimizasyon aşamaz. Sunucun ile ziyaretçin arasındaki her bin kilometre, gidiş-dönüş başına yaklaşık 10 milisaniye ekler. HTTPS bağlantısı kurmak birden fazla gidiş-dönüş gerektirdiği için bu maliyet çarpanla yansır.

Türkiye'deki ziyaretçilere hizmet veren bir site için sunucunun Türkiye'de ya da yakın bir Avrupa noktasında olması belirgin fark yaratır. Uzak bir kıtadaki sunucuda, sayfa üretimi ne kadar hızlı olursa olsun, TLS el sıkışması tek başına birkaç yüz milisaniye ekler. Mesafeyi ölçmek basittir:

# Gidiş-dönüş süresi (RTT) ölç
ping -c 5 firmaniz.com

# Yol üzerindeki atlamaları ve nerede gecikme biriktiğini gör
mtr -rwc 20 firmaniz.com

ping çıktısındaki ortalama süre yurt içi bir sunucu için tipik olarak düşük onlu milisaniyelerdedir; yüzlerce milisaniye görüyorsan sunucu çok uzaktadır ya da yol üzerinde bir sorun vardır. mtr hangi atlamada gecikmenin arttığını gösterir ve sorunun kendi sunucunda mı yoksa aradaki bir taşıyıcıda mı olduğunu ayırt etmeni sağlar.

CDN bu mesafe sorununu statik dosyalar için çözer ama dinamik sayfa üretimini kullanıcıya yaklaştırmaz; ayrımın nerede olduğunu CDN mi daha iyi hosting mi yazısında karşılaştırdım.

Yazılım Yığını: Aynı Donanımda İki Kat Fark#

Aynı fiziksel kaynaklarla iki kat farklı performans almak mümkündür ve fark yazılım yığınındadır. Üç ayar burada belirleyicidir.

Birincisi PHP sürümü. Güncel PHP sürümleri, birkaç yıl önceki sürümlere göre aynı kodu belirgin biçimde daha hızlı çalıştırır ve daha az bellek kullanır. Paketinde eski bir sürüm çalışıyorsa, panelden tek bir seçimle yapacağın yükseltme çoğu zaman en ucuz performans kazancıdır. Yükseltmeden önce mutlaka test kopyasında uyumluluğu dene.

İkincisi opcode önbelleği. Kapalı bir OPcache, her istekte tüm PHP dosyalarının yeniden derlenmesi demektir:

; php.ini - üretim için makul başlangıç
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

max_accelerated_files değeri projendeki PHP dosya sayısından büyük olmalıdır; küçükse önbellek sürekli taşar ve neredeyse hiç işe yaramaz.

Üçüncüsü web sunucusu ve önbellek katmanı. Nginx ya da LiteSpeed üzerinde kurulan tam sayfa önbelleği, PHP'yi devre dışı bırakarak yanıt süresini milisaniyelere indirir. İkisi arasındaki farkı LiteSpeed ve Apache karşılaştırması yazısında ele aldım; Nginx tarafında kurulum için Nginx FastCGI cache yapılandırma yazısına bakabilirsin.

Hangi Paket Türü Sana Uygun#

Paket türü seçimi, kaynakların paylaşılıp paylaşılmadığı ve garanti edilip edilmediği ile ilgilidir. Paylaşımlı hostingde CPU ve belleği yüzlerce siteyle paylaşırsın; sınırlar yumuşaktır ve komşu bir sitenin ani yükü seni etkileyebilir. VDS'te kaynaklar sana ayrılır ve tam kontrol sende olur. Aradaki karar noktası genellikle trafik değil, yükün dinamikliğidir.

Karar verirken şu soruyu sor: sayfalarımın yüzde kaçı önbellekten servis edilebilir? Cevap yüzde 90'sa paylaşımlı paket seni uzun süre taşır. Cevap yüzde 40'sa, yani ziyaretçilerin çoğu oturum açmış ya da sepetli geziyorsa, her istek gerçekten PHP çalıştıracak demektir ve ayrılmış kaynağa ihtiyacın vardır. Paylaşımlı paketlerin sınırlarını ve nerede tıkandığını paylaşımlı hostingde hız limitleri yazısında ayrıntılı anlattım.

Sık Yapılan Hatalar#

Ön uç sorununu paket yükselterek çözmeye çalışmak. En pahalı hata budur. TTFB zaten 150 milisaniyeyken daha güçlü bir sunucuya geçmek toplam yükleme süresini neredeyse hiç değiştirmez; sorun 3 megabaytlık görsellerdedir. Önce ölç, sonra harca.

Önbellek kurmadan kaynak artırmak. Doğru kurulmuş tam sayfa önbelleği çoğu sitede sunucu yükünü onda birine indirir. Bunu yapmadan iki kat güçlü sunucuya geçmek, aynı parayla çok daha azını satın almaktır.

Sunucuyu boş saatte test edip karar vermek. Paylaşımlı ortamda gece yarısı her şey hızlıdır. Kararını akşam yoğunluğunda alınmış ölçümlere dayandır.

Konum ile kaynağı karıştırmak. Yurt dışındaki güçlü bir sunucu, yurt içindeki mütevazı bir sunucudan daha yavaş "hissedilebilir"; çünkü ziyaretçinin gördüğü şey toplam gecikmedir. Hedef kitlen neredeyse sunucun da oraya yakın olmalıdır.

PHP sürümünü yıllarca güncellememek. Ücretsiz ve genellikle tek tıklık bir kazancı, uyumluluk korkusuyla ertelemek yaygındır. Test kopyasında dene, sonra canlıya al.

Sıkça Sorulan Sorular#

Hosting değiştirirsem sitem ne kadar hızlanır#

Hesaplayabilirsin: curl ile TTFB ve TLS sürelerini ölç, aradaki farkı bul. Bu fark, sunucunun sayfayı üretme süresidir ve paket değiştirerek iyileştirebileceğin tek bileşendir. Bu değer 800 milisaniyeyse ve iyi bir sunucuda 150 milisaniyeye inecekse, toplam yükleme süren yaklaşık 650 milisaniye kısalır. Toplam süren 5 saniyeyse geri kalan 4,3 saniye hâlâ ön uçtadır.

Paylaşımlı hosting her zaman yavaş mıdır#

Hayır. İyi yapılandırılmış, aşırı satılmamış bir paylaşımlı sunucuda önbellekli bir site son derece hızlı çalışır; çünkü istekler PHP'ye hiç ulaşmaz. Paylaşımlı paketin sorunu ortalama performans değil, öngörülemezliktir: komşu bir sitenin ani yükü ya da bir tarayıcı botunun ziyareti senin sayfa sürelerini dalgalandırabilir. Kişiye özel içerik oranı yüksekse bu dalgalanma hissedilir hale gelir.

Sunucu konumu gerçekten fark eder mi#

Eder, ama etkisi sabit ve öngörülebilirdir. Her bin kilometre gidiş-dönüş başına kabaca 10 milisaniye ekler ve HTTPS bağlantısı birden fazla gidiş-dönüş gerektirdiği için bu maliyet çarpanla yansır. Ziyaretçilerinin neredeyse tamamı Türkiye'den geliyorsa yurt içi ya da yakın Avrupa konumu belirgin fark yaratır. Küresel bir kitlen varsa statik dosyalar için CDN, dinamik içerik için ana kitlene yakın bir konum doğru bileşimdir.

NVMe disk site hızımı ne kadar etkiler#

Sitenin profiline bağlı. Statik ağırlıklı bir tanıtım sitesinde fark neredeyse yoktur, çünkü dosyalar zaten bellek önbelleğinden okunur. Veritabanı yoğun bir mağaza, forum ya da üyelik sitesinde ise fark doğrudan sayfa süresine yansır; çünkü bu sitelerde her istek çok sayıda küçük ve rastgele disk okuması üretir ve NVMe'nin asıl üstünlüğü tam olarak bu profildedir.

VDS'e geçmem için hangi işaretleri beklemeliyim#

Üç işaret nettir: yoğun saatte kaynak limiti uyarıları ya da 503 sayfaları görmeye başlaman, sayfalarının önemli bir kısmının önbelleklenemez (oturumlu, sepetli) olması, ve arka planda sürekli çalışan bir işe (kuyruk işçisi, zamanlanmış görev, özel servis) ihtiyaç duyman. Bu üçünden ikisi varsa paylaşımlı paket sana dar geliyor demektir.

Sunucumun mu sitemin mi yavaş olduğunu nasıl anlarım#

curl zaman kırılımını al ve TTFB'den TLS süresini çıkar. Kalan değer 200 milisaniyenin altındaysa sunucun sağlıklıdır ve yavaşlık ön uçtadır: görseller, JavaScript, üçüncü taraf scriptler. 800 milisaniyenin üstündeyse sunucu tarafında bir sorun vardır ama bu illa kaynak yetersizliği demek değildir; önce önbelleğin çalışıp çalışmadığını ve yavaş veritabanı sorgusu olup olmadığını kontrol et.

Kapanış#

Hosting seçiminde akılda tutman gereken dört alışkanlık var. Birincisi, kararını ölçüme dayandır: curl zaman kırılımı sana sorunun sunucuda mı ön uçta mı olduğunu on saniyede söyler. İkincisi, kaynak artırmadan önce önbelleği kur; doğru kurulmuş bir tam sayfa önbelleği çoğu sitede paket yükseltmesinden daha büyük kazanç sağlar. Üçüncüsü, paket türünü trafiğe değil önbelleklenebilirlik oranına göre seç. Dördüncüsü, sunucunun konumunu hedef kitlene göre belirle; mesafeyi hiçbir optimizasyon geri kazandırmaz.

Doğru paketi seçerken yardıma ihtiyacın olursa Clou.TR tarafında her profil için bir karşılık var. Önbellekli, orta trafikli siteler için NVMe diskli web hosting ve WordPress hosting paketleri; sepetli ve önbelleklenemez trafiği yüksek mağazalar için e-ticaret hosting; ayrılmış kaynak ve kök erişimi gerektiren projeler için VDS sunucu ya da ölçeklenebilir bulut sunucu seçenekleri var. Mevcut sitenizi taşırken kesinti yaşamamak için site taşıma, sunucu tarafını hiç kurcalamak istemiyorsanız sunucu yönetimi hizmetimizden yararlanabilirsiniz.