Çok Lokasyonlu Site Hızı Testi: CDN’i Proxy ile Doğrulama

Tek konumdan ölçüm neden yanıltır?

Bir CDN, ziyaretçiyi coğrafi olarak en yakın uç noktaya yönlendirir ve sayfayı mümkünse oradaki önbellekten verir. Siz İstanbul’dan ölçtüğünüzde İstanbul’a yakın uç nokta yanıt verir; önbellek sizin tekrar eden isteklerinizle ısınmıştır ve süreler iyi görünür. Aynı sayfa Brezilya’dan istendiğinde ya oradaki uç nokta önbelleği boş olduğu için kaynak sunucuya gider ya da o bölgede uç nokta yoktur ve istek kıtalar aşarak size gelir.

İkinci yanılgı yönlendirme katmanındadır. Birçok CDN hangi uç noktanın yanıt vereceğine DNS düzeyinde, çözümlemeyi yapan sunucunun konumuna göre karar verir. Kendi ağınızdan yaptığınız çözümleme her zaman kendi bölgenizin cevabını getirir; başka bölgedeki ziyaretçinin hangi adrese düştüğünü görmek için çözümlemenin de o bölgede yapılması gerekir. Tarayıcı tabanlı hız araçlarının çoğu birkaç sabit şehirden ölçer ve sonucu bir puan olarak verir; hangi uç noktanın yanıtladığını, önbellek durumunu ve yönlendirme zincirini göstermez.

Üçüncü yanılgı içerikle ilgilidir. Fiyat, dil ve para birimi gibi bölgeye göre değişen içerik, hız sayısının yanında doğrulanmak zorundadır. Almanya’dan gelen ziyaretçiye hâlâ Türk Lirası gösteriliyorsa hız ölçümünün bir anlamı kalmaz; test aynı anda bu içeriği de kaydeder.

Test düzeneği: proxy, hedef ve kaydedilen alanlar

Düzenek üç parçadan oluşur. Birincisi çıkış adresleridir: ölçmek istediğiniz her ülke için bir datacenter proxy. İkincisi hedef listesidir: ana sayfa, en çok ziyaret edilen içerik sayfası, bir statik varlık (büyük bir görsel ya da betik dosyası) ve varsa bir API uç noktası. Üçüncüsü kayıt tablosudur; her istek için ülke, sayfa, deneme sırası, HTTP durumu, ilk bayt süresi, toplam süre, çözümlenen adres, yanıtı veren uç nokta ve önbellek durumu yazılır.

Ölçüm aracı curl yeterlidir; proxy, ayrıntılı zamanlama ve yanıt başlıkları tek komutta alınır. Önemli ayar DNS çözümlemesinin yeridir: HTTP proxy kullanıldığında alan adını proxy sunucusu çözer ve bu zaten istediğiniz davranıştır; SOCKS5 kullanılıyorsa çözümlemenin uzakta, yani proxy tarafında yapıldığından emin olun, aksi halde kendi ağınızın DNS cevabı proxy üzerinden gider ve yönlendirme testi anlamını yitirir.

Proxy kendi gecikmesini ekler; bu pay ayrılmazsa CDN yavaş görünür. Her çıkış adresi için önce bir referans ölçümü alın: aynı proxy üzerinden, aynı bölgede barındırıldığı bilinen küçük ve hızlı bir hedefi on kez isteyin ve ortancayı yazın. Sitenizin o bölgedeki süresinden bu referansı düşerek CDN’in kendi payını bulursunuz. Gecikmeyi DNS, TCP, TLS ve ilk bayt bileşenlerine ayırma yöntemi proxy gecikme ölçümü rehberinde ayrıntılı anlatıldı; burada aynı komut seti kullanılır.

Üç kontrol: uç nokta eşleşmesi, önbellek isabeti, coğrafi yönlendirme

Uç nokta eşleşmesi: CDN sağlayıcıları yanıtı veren uç noktayı bir yanıt başlığında belirtir; başlığın adı ve biçimi sağlayıcıya göre değişir, kimi bir şehir ya da havalimanı kodu, kimi sunucu kimliği yazar. Her bölgeden gelen yanıtta bu başlığı kaydedin ve beklenen bölgeyle karşılaştırın. Kanada çıkışı ABD doğu kıyısındaki bir uç noktaya düşüyorsa bu normal olabilir; Almanya çıkışı Asya’daki bir uç noktaya düşüyorsa yönlendirmede bir sorun vardır.

Önbellek isabeti: Aynı sayfanın aynı bölgeden art arda iki isteğinde ikinci yanıt önbellekten gelmelidir. Önbellek durumunu bildiren başlık da sağlayıcıya göre değişir, ama isabet ve ıskalama ayrımı hemen hepsinde vardır. İkinci istek de ıskalıyorsa ya sayfa önbelleğe alınmaz olarak işaretlenmiştir, ya çerez ve sorgu parametreleri anahtarı bozuyordur ya da o bölgedeki uç nokta önbellek kapasitesine sahip değildir. Ana sayfanın ıskalaması ile statik varlığın ıskalaması farklı nedenlere işaret eder; ikisini ayrı okuyun.

Coğrafi yönlendirme: Her bölgeden çözümlenen IP adresini kaydedin. Aynı alan adı beş ülkede beş farklı adrese çözülüyorsa CDN bölgesel yönlendirme yapıyordur; hepsi aynı adrese çözülüyorsa ya anycast kullanılıyordur ya da bölgesel yönlendirme hiç kurulmamıştır. Anycast’te adres aynı kalır ama yanıtı veren uç nokta değişir; bu yüzden yönlendirme yalnız IP’den değil, uç nokta başlığıyla birlikte okunur. Bölgeye göre değişmesi gereken içerik de bu adımda doğrulanır: para birimi, dil ve yönlendirme sayfası beklenen bölgeye ait mi?

Örnek protokol: beş ülke, dört hedef, iki istek, on tekrar

Varsayımlar şöyle olsun: çıkış ülkeleri ABD, Birleşik Krallık, Hollanda, Almanya ve Kanada; hedefler ana sayfa, bir içerik sayfası, bir büyük görsel ve bir API uç noktası; her hedef için önce soğuk sonra sıcak istek; sıcak istek on kez tekrarlanır ve ortancası alınır. Toplam istek sayısı beş ülke çarpı dört hedef çarpı on bir istek, yani 220 istektir ve tek bir oturumda birkaç dakikada biter.

Kayıt tablosunun satırı şu alanları taşır: ülke, hedef, soğuk mu sıcak mı, HTTP durumu, çözümlenen adres, uç nokta başlığı, önbellek başlığı, ilk bayt süresi, toplam süre, yanıt boyutu ve bölgesel içerik işareti. Son sütun bir evet-hayır alanıdır: yanıtta beklenen dil ya da para birimi var mı? Her ülkenin referans ölçümü ayrı bir satıra yazılır ve ilk bayt süresinden düşülür.

Protokol haftalık çalıştırıldığında tablo zaman serisine dönüşür. CDN ayarı, kaynak sunucu taşınması ya da yeni bir bölgenin açılması gibi değişikliklerden önce ve sonra aynı protokol çalıştırılır; iki tablo arasındaki fark değişikliğin bölgesel etkisidir. CDN sorunlarının çoğu haftalık seride ortaya çıkar; tek ölçüm yalnız o anki durumu gösterir.

Sonuçları okumak: dört tipik bulgu

Bir bölgede sürekli ıskalama: Sıcak istek de önbellekten gelmiyorsa ve diğer bölgelerde geliyorsa o bölgedeki uç nokta önbellek tutmuyordur ya da trafik o bölgeye hiç düşmediği için önbellek hiç ısınmıyordur. Çözüm CDN tarafındadır: bölgesel önbellek ayarı, katmanlı önbellek ya da o bölge için ayrı bir kural.

İsabet var ama ilk bayt yüksek: Yanıt önbellekten geliyor ama süre diğer bölgelerin birkaç katı. Referans ölçümü düşüldükten sonra fark sürüyorsa yanıtı veren uç nokta beklenenden uzaktadır; uç nokta başlığı bunu gösterir. Çoğu zaman neden yönlendirme kuralındaki bir eksikliktir, bazen de sağlayıcının o bölgede uç noktası yoktur ve çözüm sağlayıcı seçimine kadar gider.

Yanlış bölgeye yönlendirme: Çözümlenen adres ya da uç nokta başlığı, çıkış ülkesinden uzak bir bölgeyi gösteriyor. Neden çoğunlukla DNS tarafındadır: CDN, çözümlemeyi yapan sunucunun konumuna bakar ve o sunucu proxy’nin bulunduğu ülkede değilse yanlış karar verir. Bu bulgu önce test düzeneğinde doğrulanır; çözümleme gerçekten proxy tarafında yapılıyorsa sorun sitenin yönlendirme kuralındadır.

Bölgesel içerik uyumsuzluğu: Hız normal, önbellek isabetli, ama Almanya çıkışına Türkçe sayfa ve Türk Lirası gösteriliyor. Sorun uygulama katmanındadır; coğrafi tespit önbellekle çakışır: önbellek anahtarı ülkeyi içermiyorsa ilk ziyaretçinin bölgesel içeriği herkese dağıtılır. Önbellek anahtarına ülke eklenir ya da bölgesel içerik önbelleğin dışına alınır.

Static mi rotating mi: bu test için hangi datacenter ürünü?

Haftalık tekrarlanan test için static IPv4 datacenter proxy uygundur: DatacenterProxy kataloğunda ABD, Birleşik Krallık, Hollanda, Almanya ve Kanada lokasyonlarında sabit adresler, IP başına dönemsel ücretle sunulur. Adres sabit olduğu için her haftanın ölçümü aynı çıkış noktasından yapılır ve zaman serisi karşılaştırılabilir kalır; referans ölçümü de bir kez alınıp aylarca kullanılabilir.

Geniş coğrafyayı tek seferde taramak için rotating IPv4 datacenter proxy daha pratiktir: 180’den fazla lokasyon, GB bazlı tek seferlik ücret. Yeni bir pazara açılmadan önce o pazarın birkaç ülkesinden tek seferlik ölçüm almak ya da bir CDN sağlayıcısının bölgesel kapsamını satın almadan önce görmek bu ürünle yapılır. Rotating havuzda çıkış adresi her istekte değişebileceği için soğuk ve sıcak istek çiftinin aynı adresten gittiğinden emin olunmalı, oturum bazlı rotasyon seçilmelidir.

Hedef alan adının AAAA kaydı varsa IPv6 yolu ayrı test edilir; CDN’lerin IPv6 uç nokta dağılımı IPv4 ile aynı olmak zorunda değildir ve IPv6 ziyaretçileri farklı bir uç noktaya düşebilir. Static IPv6 datacenter proxy, Almanya, ABD, Avustralya, Brezilya, Japonya, Güney Kore, Hindistan ve Güney Afrika gibi lokasyonlarla IPv4 listesinin dışındaki bölgeleri de kapsar. Ülke seçiminin hedef pazar ve gecikme açısından değerlendirilmesi lokasyon seçimi rehberinde var.

Test ne sıklıkla çalışır ve ne zaman tetiklenir?

Dört tetikleyici vardır: her dağıtımdan sonra, CDN ya da DNS ayarı değiştiğinde, yeni bir pazara açılmadan önce ve sabit bir haftalık takvimde. Dağıtım sonrası test yalnız sıcak istek ve önbellek isabetine bakar; ayar değişikliği sonrası test tam protokolü çalıştırır. Haftalık test en ucuz güvencedir: 220 isteklik protokol, yalnız HTML ve tek bir görselle, birkaç megabayt trafik üretir.

Sürekli izleme isteyen ekipler protokolü saatlik çalıştırabilir, ama bu noktada ölçüm kendisi bir yük olur: her saat beş bölgeden soğuk istek atmak önbelleği gereksiz yere ısıtır ve CDN istatistiklerini bozar. Saatlik izlemede yalnız sıcak istek atılır, soğuk istek günde bir kez bırakılır. Ölçüm hesabının hız sınırına takılmaması için her bölgeden gelen istekler arasında bir iki saniye bekleme yeterlidir.