Sunucu Performansı ve TTFB
Sunucu Yanıt Süresi Hangi Katmanlarda Yavaşlar?
TTFB 800 milisaniye çıktığında ne yapmalı? Çoğu ekip "sunucu yavaş" sonucuna varır ve daha güçlü bir hosting planına geçmeyi ya da sunucu yapılandırmasını baştan gözden geçirmeyi düşünür. Oysa 800 milisaniyelik TTFB tek bir gecikmenin değil, birbirini izleyen birkaç katmanın toplamıdır. Bu katmanların hangisi ne kadar süre harcadığı bilinmeden doğru yerde müdahale etmek mümkün değildir.
Sunucu yanıt süresi tarayıcının isteği gönderdiği andan ilk baytı aldığı ana kadar geçen süredir. Bu zaman diliminde istek; DNS çözümlemesinden geçer, TCP bağlantısı kurulur, TLS el sıkışması tamamlanır, reverse proxy isteği yönlendirir, uygulama katmanı işlemi gerçekleştirir, gerekiyorsa veritabanına gidip döner ve yanıt oluşturulur. Her katman kendi payını alır; toplam gecikme bu payların birikimidir.
Katmanları ayrıştırmak hem teşhis hem de önceliklendirme açısından kritiktir. DNS optimizasyonu yaparak kazanılabilecek şey genellikle 20-50 ms'dir. Yanlış yapılandırılmış tek bir veritabanı sorgusu ise aynı TTFB'ye 400 ms ekleyebilir. Aynı toplam süre çok farklı köklere işaret edebilir; doğru katmanı tespit etmeden yapılan optimizasyon çoğu zaman boşa gider.
Bir gecikmede birden fazla el var
TTFB tek bir ölçümdür ama tek bir olayı temsil etmez. Tarayıcı isteği gönderdiğinde sırasıyla birçok adım devreye girer; bu adımların her biri zaman harcar ve toplam gecikmeye katkıda bulunur. Geliştirici araçlarındaki Network sekmesi bu katmanları kısmen görünür kılar: DNS Lookup, Initial Connection, SSL ve Waiting sürelerini ayrı bloklar olarak gösterir.
Buradaki kritik ayrım şudur: DevTools'un gösterdiği "Waiting (TTFB)" değeri tarayıcının isteği gönderdikten sonra ilk baytı beklediği süreyi kapsar. Ancak bu bekleme süresi içinde arka planda birden fazla katman çalışır. Ağ rotası, sunucu yazılımı, uygulama kodu ve veritabanı bu katmanların başında gelir. Ön yüzdeki katmanlar (DNS, TCP, TLS) DevTools ile görünürken, arka yüzdeki katmanlar (uygulama, veritabanı) ancak sunucu taraflı araçlarla ayrıştırılabilir.
DNS çözümlemesi: görünmez ama ölçülebilir
DNS çözümlemesi, domain adının IP adresine dönüştürüldüğü adımdır. İlk ziyarette bu süre genellikle 20-120 ms arasında değişir; tekrar ziyarette işletim sistemi ya da tarayıcı önbelleğinden karşılandığı için sıfıra yaklaşır. Bu asimetri, DNS gecikmesini karşılaştırmalı testlerde yanıltıcı kılar: soğuk başlatmada ölçülen süre, gerçek kullanıcıların büyük çoğunluğunun deneyimlediğinden farklı olabilir.
DNS çözümlemesinin yavaşladığı durumlar arasında yetersiz TTL yapılandırması, DNS sağlayıcısının coğrafi kapsamının kısıtlı olması ve çok sayıda alt alan adı kullanımı sayılabilir. Üçüncü taraf kaynaklar için preconnect ve DNS prefetch ipuçları bu adımı kritik yolun dışına taşıyabilir. Birincil domain için ise yetkili bir DNS sağlayıcısı seçmek ve uygun TTL değerleri belirlemek gecikmeyi anlamlı ölçüde azaltır.
TCP bağlantısı ve TLS el sıkışmasının maliyeti
DNS çözümlemesi tamamlandıktan sonra tarayıcı sunucuya TCP bağlantısı kurar. Bu süreç SYN paketi gönderilmesi, sunucudan SYN-ACK alınması ve ACK gönderilmesi adımlarından oluşur. HTTPS bağlantılarında buna ek olarak TLS el sıkışması gerçekleşir: sertifika doğrulama, şifreleme paketi müzakeresi ve oturum anahtarı oluşturma. Bu iki adım birlikte 50-300 ms arasında sürebilir; kullanıcı ile sunucu arasındaki coğrafi mesafe gecikme üzerinde doğrudan etkilidir.
HTTP/3 bu maliyeti azaltır: QUIC protokolü TCP el sıkışması ile TLS el sıkışmasını tek bir gidiş-dönüşe indirir. Mevcut bağlantının yeniden kullanılması (keep-alive, HTTP/2 ve HTTP/3'te varsayılan davranış) tekrar eden isteklerde bu maliyeti büyük ölçüde ortadan kaldırır. CDN kullanıldığında ise bu el sıkışmaları uzak origin yerine coğrafi olarak yakın edge sunucusunda tamamlanır; ağ gecikmesi otomatik olarak düşer.
Reverse proxy katmanının eklediği süre
Nginx, HAProxy ya da Varnish gibi reverse proxy'ler genellikle uygulama sunucusunun önünde konumlanır. İstek buradan geçerken SSL sonlandırma, sıkıştırma, istek yönlendirme ve statik dosya sunumu gibi işlemler gerçekleşebilir. Doğru yapılandırıldığında bu katman milisaniyeler düzeyinde yük ekler. Yanlış yapılandırıldığında ise beklenmedik gecikmeler ortaya çıkabilir.
Reverse proxy gecikmesinin yükseldiği tipik durumlar şunlardır: upstream bağlantı havuzunun dolması yüksek eşzamanlı istek sayısında darboğaz oluşturur, buffer sınırlarına ulaşılması akışı durdurur ve SSL sertifika doğrulama sorunları bağlantı süresini uzatır. Upstream yanıt süresini proxy erişim günlüklerinden izlemek, gecikmenin proxy mı yoksa uygulama katmanı mı kaynaklı olduğunu net biçimde ortaya koyar. Bu ayrım yapılmadan yapılan optimizasyon yanlış yere odaklanma riskini taşır.
Uygulama katmanı: istek işleme süresi
Uygulama katmanı TTFB'nin en değişken parçasıdır. Bir PHP uygulaması, Node.js servisi ya da Python web çerçevesi isteği aldığında; rotayı belirler, kimlik doğrulama kontrollerini yapar, iş mantığını çalıştırır ve yanıtı oluşturur. Bu süre uygulamanın mimarisine, kod kalitesine ve çalışma zamanı koşullarına göre birkaç milisaniyeden birkaç saniyeye kadar uzayabilir.
Uygulama katmanındaki gecikmeyi izole etmek için en doğrudan yol sunucu taraflı izleme araçlarıdır. Bu araçlar hangi fonksiyonun ya da ara yazılımın ne kadar süre harcadığını gösterir; darboğaz genellikle birkaç noktada yoğunlaşır. Yavaş düzenli ifade işlemleri, ağır şablon oluşturma, senkronize G/Ç operasyonları ve yetersiz bellek tahsisi bu katmanda sık karşılaşılan sorunlardır. Profiling olmadan yapılan kod optimizasyonu ise çoğu zaman yüksek etkili noktaları atlar.
Veritabanı sorgusu ve gecikmenin sızdığı yer
Dinamik içerik üreten uygulamaların büyük bölümünde uygulama katmanı veritabanına bir ya da birden fazla sorgu gönderir. Sorgu süresi TTFB'nin içindedir: uygulama yanıt oluşturmaya ancak veritabanı yanıt döndürdükten sonra başlayabilir. Bu nedenle yavaş bir veritabanı sorgusu doğrudan yavaş bir TTFB olarak görünür; iki değer arasındaki korelasyon neredeyse bire birdir.
Veritabanı kaynaklı gecikmenin belirtileri belirgindir: TTFB sayfadan sayfaya dramatik biçimde değişir, aynı sayfa yüksek trafik altında orantısız yavaş davranır ya da belirli filtre veya sıralama kombinasyonlarında ani artışlar gözlemlenir. Sorgu planı analizi, eksik indeks tespiti ve N+1 sorgu antipatternlerini çözmek bu katmanda en yüksek iyileştirmeyi sağlayan önlemlerdir. Sorgular optimize edildikten sonra önbellekleme katmanını devreye almak, tekrarlayan veritabanı yükünü önemli ölçüde azaltır.
Önbellekleme katmanının devreye girdiği nokta
Önbellekleme, uygulama ve veritabanı katmanlarını tamamen devre dışı bırakarak TTFB'yi dramatik biçimde düşürebilir. Sayfa önbelleğe alındığında istek reverse proxy ya da CDN tarafından karşılanır; uygulama çalıştırılmaz, veritabanına gidilmez. Sonuç olarak yüzlerce milisaniye sürebilecek bir işlem birkaç milisaniyeye iner.
Önbelleklemenin etkin olmadığı ya da yanlış yapılandırıldığı durumlar TTFB'yi şişiren gizli bir kaynaktır. Cache-Control başlıklarının yanlış ayarlanması, Vary başlığının çok geniş kapsamlı olması ya da oturum çerezlerinin önbellek anahtarını parçalaması, teoride önbelleğe alınması gereken içeriklerin her seferinde yeniden üretilmesine yol açar. CDN üzerinden sunulan içeriklerde önbellek hit oranı, TTFB dağılımını doğrudan belirler. Hit oranı yüksekse kullanıcıların büyük çoğunluğu hızlı yanıt alır; hit oranı düşükse origin her seferinde tam işlem maliyetini üstlenir.
CDN edge'inin TTFB üzerindeki etkisi
CDN kullanıldığında istek önce coğrafi olarak yakın bir edge sunucusuna ulaşır. İçerik edge'de önbelleğe alınmışsa (cache hit) yanıt doğrudan buradan döner; origin'e istek gitmez. Bu durumda TTFB yalnızca kullanıcı ile edge arasındaki ağ gecikmesini ve edge'in yanıt üretme süresini yansıtır. Coğrafi optimizasyon en yüksek etkisini bu noktada üretir.
Ancak CDN her zaman TTFB'yi iyileştirmez. Cache miss durumunda edge isteği origin'e yönlendirir; toplam gecikme artık kullanıcı-edge, edge-origin, origin işlem süresi ve dönüş zincirinin tamamından oluşur. Bu zincir bazı durumlarda doğrudan origin erişiminden daha uzun sürebilir. CDN yapılandırmasında önbellek hit oranını yüksek tutmak ve populer içerikleri önceden ısıtmak (cache warming) bu riski minimize eder.
Her katmanı izole etmek için ölçüm araçları
Katman tespiti belirli araçların bir arada kullanımını gerektirir. Tarayıcı geliştirici araçlarının Network sekmesi DNS Lookup, Initial Connection, SSL ve Waiting sürelerini görünür kılar; bu değerler ön yüzdeki katmanları analiz etmek için yeterlidir. Ancak uygulama ve veritabanı katmanlarını ayırt etmek sunucu taraflı verilere ihtiyaç duyar.
Uygulama performansı izleme araçları her isteğin uygulama katmanında ne kadar süre harcadığını ve bu sürenin hangi bileşenlere dağıldığını gösterir. Sunucu erişim günlükleri upstream yanıt süresi ile toplam istek süresi farkını ortaya koyar. Veritabanı yavaş sorgu günlükleri eşiği aşan sorguları listeler. Bu üç kaynağın birlikte okunması genellikle asıl darboğazı net biçimde işaret eder; tek bir kaynak çoğu zaman eksik tablo sunar.
Waterfall analizi ile katman tespiti
Detaylı performans test araçlarının ürettiği waterfall görünümü her isteğin aşamalarını zaman çizelgesi üzerinde gösterir. DNS, bağlantı, SSL, gönderme, bekleme ve alma adımları ayrı renklerle belirtilir. İlk isteğin waterfall'una bakıldığında hangi adımın toplam sürenin büyük bölümünü oluşturduğu genellikle ilk bakışta anlaşılır.
Tekrar eden isteklerde DNS ve TCP adımları ortadan kalkar; yalnızca SSL (bazı durumlarda), gönderme ve bekleme kalır. Bekleme süresinin orantısız uzun olması uygulama ya da veritabanı katmanına işaret eder. Tersine, DNS ya da bağlantı adımının uzun olması ağ katmanı sorunlarını düşündürür. Farklı coğrafi konumlardan gerçekleştirilen testler ise ağ gecikmesinin mi yoksa origin işlem süresinin mi baskın olduğunu net biçimde ortaya koyar; bu ayrım önceliklendirme açısından belirleyicidir.
Katmanlar arasında önceliklendirme
Hangi katmandan başlanacağı mevcut TTFB değerine, trafik profiline ve site mimarisine göre belirlenir. Genel bir başlangıç noktası olarak şu sıra işlevseldir: önce önbellekleme durumunu kontrol et — önbellek düzgün çalışıyorsa uygulama ve veritabanı katmanları büyük ölçüde devre dışı kalır. Ardından veritabanı sorgularına bak — bu katman en yüksek varyansı ve en büyük gecikme potansiyelini taşır. Sonra uygulama katmanı profillenir. DNS ve TCP/TLS katmanları ise genellikle CDN kullanımı ve modern protokol desteğiyle büyük ölçüde çözülür.
TTFB bileşenlerini ayrı ayrı ölçmeden yapılan önceliklendirme yanıltıcıdır. 600 ms TTFB'nin 500 ms'i veritabanından kaynaklanıyorsa DNS optimizasyonu bu faturanın küçük bir bölümünü etkiler. Tam tersi de geçerlidir: bazı durumlarda uygulama gecikmesi düşüktür ama DNS ve TCP adımları beklenmedik biçimde uzundur. Sayısal veri olmadan yapılan tahmin genellikle yüksek etkili noktayı kaçırır.
Ölçüm olmadan optimizasyon neden işe yaramaz
Sunucu yanıt süresi optimizasyonu katman sayısı ve karmaşıklığı nedeniyle etkisi yüksek ama tespiti güç bir alan olmaya devam ediyor. Her katmanın kendi ölçüm yöntemi ve araç seti vardır: DNS için TTL ve sağlayıcı seçimi; TCP/TLS için protokol ve CDN; reverse proxy için yapılandırma ve bağlantı havuzu; uygulama için profiling ve kod kalitesi; veritabanı için sorgu optimizasyonu ve indeks; önbellekleme için doğru başlıklar ve hit oranı. Bu listedeki her madde kendi başına bir optimizasyon alanıdır.
TTFB'yi tek bir sayı olarak değil, birbirine bağlı adımların toplamı olarak görmek doğru katmana odaklanmayı mümkün kılar. Her müdahalenin etkisi de ölçülebilir: bir değişiklik öncesinde ve sonrasında aynı katmanın süresi kayıt altına alınırsa, kazanım nettir. Bu yaklaşım hem yapılan işin değerini somutlaştırır hem de bir sonraki adımın nereye yönelmesi gerektiğini gösterir.
Sunucu yanıt süresi optimizasyonu genellikle tek bir değişiklikle değil, birkaç katmanda yapılan ardışık iyileştirmelerle sonuç verir. Bir katmandaki kazanım bazen başka bir katmanın darboğazını görünür kılar: veritabanı sorgularını hızlandırmak uygulama katmanındaki başka bir yavaşlamayı gün yüzüne çıkarabilir. Bu durum bir sorun değil, sürecin doğal akışıdır; her katman çözüldükçe bir sonraki sınırlayıcı faktör öne çıkar.
Önbellekleme bu zincirin en verimli kesme noktasıdır. Sayfa önbelleklendiğinde uygulama ve veritabanı katmanları tamamen bypass edilir; TTFB birkaç milisaniyeye iner. Bu nedenle önbellek yapılandırmasını kontrol etmek ve hit oranını yüksek tutmak, diğer tüm katman optimizasyonlarından önce gelen bir temel adımdır. Önbellekleme çalışıyorsa diğer katmanlardaki sorunların etkisi zaten sınırlıdır; çalışmıyorsa tüm yük her seferinde uygulama ve veritabanı üzerinde birikmektedir.
Ölçüm olmadan yapılan optimizasyon tahmin üzerine kuruludur. Hangi katmanın ne kadar süre harcadığını sayısal olarak bilmek, her müdahalenin etkisini de somutlaştırır. TTFB ayrıştırılmadan yaklaşılan bir sunucu optimizasyon çalışması, doğru kapıya değil en görünür kapıya çalmak demektir; bu iki şey her zaman aynı yerde değildir.