Mobil Proxy Kalitesi Nasıl Ölçülür: 7 Metrik, Protokol ve Scriptler

Giriş: Neden tek bir hız rakamı hiçbir şeyi çözmez

Bir mobil proxy seçtiğinizi ve üzerinde güzel bir yazı gördüğünüzü hayal edin: 50 megabit hız. Kulağa ikna edici geliyor, değil mi? Ancak bu rakam, proxy'nin gerçek işte nasıl davranacağı hakkında neredeyse hiçbir şey söylemez. Hız, kalitenin yalnızca bir yönüdür ve en önemlisi de değildir. İnsanları çoğu zaman yavaş bir kanal değil, istikrarsızlık hayal kırıklığına uğratır: proxy bazen anında yanıt verir, bazen birkaç saniye donar.

Bu kılavuzda, mobil proxy kalitesini dürüst ve sistematik bir şekilde ölçmeyi öğreneceksiniz. Yedi temel metriği kavrayacak, bash ve Python'da hazır scriptler edinecek, tek tip bir ölçüm protokolü öğrenecek ve sonuçları doğru okumayı başaracaksınız. Sonunda verileri tek bir tabloya döküp iki tedarikçiyi objektif olarak karşılaştırabileceksiniz.

Sonuç olarak ne elde edeceksiniz: kendi test yönteminiz, hazır araçlar ve hangi sayıların endişe verici olduğuna dair bir anlayış. Reklam rakamlarına inanmayı bırakacak ve kendi ölçümlerinize güveneceksiniz.

Bu kılavuz kimler için: mobil proxy satın alan veya kullanan ve neye para ödediğini anlamak isteyenler için. Her adım ayrıntılı olarak açıklandığından yeni başlayanlar için uygundur. İleri düzey kullanıcılar için de unsurlar var: yüzdelik dilimler, uzun süreli testler, dağılımların yorumlanması.

Önceden bilmeniz gerekenler: terminal açmayı ve komutları kopyalamayı bilmek yeterli. Programlama deneyimi şart değil. Gerekli olan her şeyi işin içinde açıklayacağız.

Ne kadar zaman gerekli: temel ölçümler yaklaşık iki-üç saatinizi alır. Tam günlük bir test elbette 24 saat sürer, ancak arka planda çalışır ve sürekli dikkatinizi gerektirmez. Okuma ve kurulum için rahat bir akşam ayırın.

Neden tek bir test hiçbir şeyi kanıtlamaz. Mobil ağ kendi hayatını yaşar. Bir saniye baz istasyonu boştur, diğer saniye aşırı yüklenmiştir. Tek bir istek yaparsanız ve hızlı çıkarsa, bu bir tesadüftür. Gerçek tabloyu ancak zamana yayılmış düzinelerce ve yüzlerce ölçümden oluşan bir seri verir. Bu nedenle tek seferlik değil seriler halinde ölçecek ve ortalamaya değil dağılıma bakacağız.

Ön Hazırlık: Araçlar ve Tek Tip Protokol

Düğmelere basmadan önce çalışma setimizi hazırlayalım. Doğru hazırlık, rakamlarınızın karşılaştırılabilir olmasını garanti eder.

Gerekli Araçlar

• curl - komut satırından istek göndermek için kullanılan araç. Çoğu sistemde zaten kuruludur.
• Python sürüm 3.8 veya daha yenisi - metrikleri ve yüzdelik dilimleri hesaplayan script için.
• Terminal - işletim sisteminizin komut satırı.
• Metin düzenleyici - scriptleri ve notları kaydetmek için.
• Proxy erişim bilgileri - mobil proxy'nizin adresi, portu, kullanıcı adı ve şifresi.

Her Şeyin Kurulu Olduğunu Nasıl Kontrol Edersiniz

1. Terminali açın.
2. curl --version komutunu yazın ve Enter'a basın.
3. Sürüm numarasını görürseniz curl hazır demektir.
4. python3 --version yazın ve Enter'a basın.
5. Python 3.11 gibi bir şey görürseniz her şey yolunda.

İpucu: python3 bulunamazsa, Python'u resmi geliştirici sitesinden indirin. Windows'ta kurulum sırasında "Add Python to PATH" seçeneğini mutlaka işaretleyin, aksi takdirde terminal komutu tanımaz.

Referans Uç Noktaları Seti

Uç nokta (endpoint), istek göndereceğimiz adrestir. Gerçekçi hedefler seçmek çok önemlidir; tıpkı çalışacağınız hedeflere benzeyenler. Proxy'yi yalnızca hız testi için özel sunucularda test etmeyin; bunlar gerçek yükü yansıtmaz.

Üç-dört farklı adres hazırlayın. Örneğin, IP adresi kontrol sayfası, hafif bir metin sayfası ve çalışmayı planladığınız bir-iki kaynak. Farklı hedefler farklı bir tablo çizer ve bu normaldir.

⚠️ Dikkat: Yalnızca kurallarına uygun olarak erişilebilen ve yasaları ihlal etmeyen kaynakları kullanın. Proxy'leri ve test scriptlerini yasaya veya hizmet koşullarına aykırı eylemler için kullanmayın.

Tek Tip Ölçüm Protokolü

Karşılaştırmanın adil olması için koşulları sabitleyin ve farklı tedarikçiler arasında değiştirmeyin.

• Sabit gün saati. Her iki proxy'yi de aynı zaman diliminde ölçün. Mobil ağ öğle vakti ve gece farklı davranır.
• Minimum deneme sayısı. Her metrik için en az birkaç düzine istekten oluşan bir seri yapın. Ne kadar çok deneme olursa sonuç o kadar güvenilir olur.
• Aynı uç noktalar. Her iki proxy'yi de aynı adres seti üzerinde test edin.
• Aynı zaman aşımı ayarları. Tüm istekler için tek tip bir bekleme limiti belirleyin.
• Aynı bilgisayar ve kanal. Test ortasında cihaz değiştirmeyin.

İpucu: Her tedarikçi için ayrı bir klasör oluşturun ve logları oraya koyun. Böylece karşılaştırma sırasında hiçbir şeyi karıştırmazsınız.

✅ Kontrol: curl ve Python'u kurdunuz, uç nokta listenizi hazırladınız ve koşul protokolünü yazdınız. Şimdi teoriye geçebiliriz.

Temel Kavramlar Basit Dille

Her adımda karşınıza çıkacak terimleri açıklayalım. Bu kelimeleri anlamak başarının yarısıdır.

Gecikme (Latency)

Gecikme, isteğin gönderilmesi ile yanıtın alınması arasındaki süredir. Milisaniye cinsinden ölçülür. Ne kadar küçükse o kadar iyidir. Dağlara bağırıp yankıyı beklediğinizi hayal edin: gecikme, ilk ses duyulana kadarki boşluktur.

TTFB

TTFB (Time to First Byte), sunucunun yanıt vermeye başladığı anlamına gelir. Bu, gecikmenin en önemli kısmıdır çünkü proxy ve sunucunun isteğinize ne kadar hızlı tepki verdiğini, ana içeriğin iletilmesinden önce gösterir.

Bant Genişliği (Throughput)

Bant genişliği, proxy'nin saniyede ne kadar veri aktarabildiğidir. Reklamlarda belirtilen hız budur. Önemlidir, ancak yalnızca diğer metriklerle birlikte anlamlıdır.

Jitter (Titreşim)

Jitter, istekten isteğe gecikmedeki dalgalanmadır. Bir yanıt 100 milisaniyede, sonraki 105 milisaniyede, üçüncüsü 98 milisaniyede gelirse jitter küçüktür ve bu iyidir. Değerler 80'den 900'e sıçrıyorsa jitter büyüktür ve çalışma dengesiz olur.

Başarılı Yanıt Oranı

Bu, hatasız ve kesintisiz olarak başarıyla tamamlanan isteklerin yüzdesidir. Metrik güvenilirliği gösterir. Proxy hızlı olabilir, ancak her on istekten biri düşerse onunla çalışmak acı vericidir.

Yüzdelik Dilimler p50, p95 ve p99

Bunlar değer dağılımını tanımlamanın bir yoludur. p50 yüzdelik dilimi medyandır: isteklerin yarısı bu değerden hızlı, yarısı daha yavaştır. p95, isteklerin %95'inin bu süre içinde tamamlandığı, %5'inin daha kötü olduğu anlamına gelir. p99 ise en yavaş durumların davranışını gösterir.

İpucu: Ana kuralı unutmayın: Ortalama değer yanıltır, yüzdelik dilimler gerçeği söyler. Dokuz hızlı ve bir tane on saniye takılı kalan yanıtınız varsa ortalama tolere edilebilir görünür, ancak p99 hemen sorunu gösterir.

Yavaş ile Dengesiz Arasındaki Fark

Yavaş bir proxy istikrarlı bir şekilde büyük gecikme değerleri verir. Bu öngörülebilirdir. Dengesiz bir proxy ise bazen mükemmel, bazen berbat sonuçlar verir. Çoğu zaman dengesizlik, istikrarlı bir yavaşlıktan daha zararlıdır çünkü plan yapılamaz.

✅ Kontrol: Gecikme, TTFB, bant genişliği, jitter, başarılı yanıt oranı ve yüzdelik dilimleri anlıyorsunuz. Harika, şimdi uygulamaya geçiyoruz.

Adım 1: Erişilebilirliği ve Başarılı Yanıt Oranını Ölçme

Bu aşamanın amacı: Proxy'nin isteklere ne kadar güvenilir yanıt verdiğini öğrenmek ve hangi hataların oluştuğunu anlamak.

Ne yapıyoruz

Bir dizi aynı isteği (birkaç düzine) gönderecek ve kaç tanesinin başarıyla tamamlandığını sayacağız. Ayrıca hataları türlerine göre toplayacağız: zaman aşımları, bağlantı kopmaları, hata kodlu yanıtlar.

Adım Adım Talimat

1. Terminali açın.
2. Proxy erişim dizesini şu formatta hazırlayın: kullanıcı adı, şifre, adres ve port.
3. Basit bir döngü kullanarak bir dizi istek gerçekleştirin; her bir curl komutu proxy üzerinden uç noktanıza erişir.
4. Her istek için yanıt kodunu ve başarı veya hata durumunu kaydedin.
5. Seri tamamlandıktan sonra başarılı yanıtların yüzdesini hesaplayın.

Tek bir istek için temel komut şöyle görünür: proxy bayrağı, bekleme süresi bayrağı ve adres içeren curl. --max-time bayrağı bekleme süresini sınırlar, böylece takılı kalan bir istek tüm seriyi durdurmaz.

Sonuç Nasıl Okunur

Yanıtları gruplara ayırın. Başarılı olanlar normal kodlu yanıtlardır. Zaman aşımlarını ayrı sayın; sunucunun zamanında yanıt vermediği durumlar. Bağlantı kopmalarını ayrı sayın. Hata kodu veren yanıtları ayrı sayın.

Dikkat: Hata dağılımı, toplam sayılarından daha önemlidir. Tüm arızalar zaman aşımı ise sorun hız veya ağ yüküdür. Bağlantı kopmaları ise proxy'nin mobil kanal seviyesinde dengesiz olabileceğini gösterir.

İpucu: Beş istekle sonuç çıkarmayın. Anlamlı minimum seri birkaç düzinedir. Önemli bir karar için yüzlerce istek yapın.

Olası Sorunlar

• Tüm istekler başarısız. Kullanıcı adı, şifre, adres ve portu kontrol edin. Tek bir yazım hatası her şeyi bozar.
• İsteklerin bir kısmı sonsuza dek takılı kalır. Zaman sınırlamasını mutlaka kullanın, aksi takdirde seri tamamlanmaz.
• Sunucu hata kodları dalgalanıyor. Hedef kaynağın kendisi dengesiz olabilir. Kontrol için başka bir uç nokta deneyin.

✅ Kontrol: Başarılı yanıt sayısı, her hata türünün sayısı ve proxy'nin nerede takıldığına dair bir anlayışa sahipsiniz.

Adım 2: Gecikmeyi ve TTFB'yi Yüzdelik Dilimlerle Ölçme

Bu aşamanın amacı: Yanıltıcı ortalamaya değil dağılıma dayalı dürüst bir gecikme tablosu elde etmek.

Ortalama Neden Yanıltıcıdır

Diyelim ki on isteğiniz var. Dokuzu yüz milisaniyede geldi, biri beş saniye takıldı. Ortalama yaklaşık altı yüz milisaniye gösterir ve bu her iki yönde de yalandır. Aslında proxy neredeyse her zaman hızlıdır, ancak bazen felaket derecede yavaştır. Yüzdelik dilimler bunu dürüstçe gösterir.

curl -w Bayrağı ile Çıktı Biçimi

curl aracı, ayrıntılı zaman dökümü verebilir. -w bayrağı belirli göstergeleri talep etmenizi sağlar. Bizim için en yararlı değişkenler: time_starttransfer - aslında TTFB, ilk bayta kadar geçen süre. Ayrıca time_connect - bağlantı kurma süresi ve time_total - toplam istek süresi vardır.

1. curl komutunu -o bayrağıyla yanıt gövdesini hiçbir yere yönlendirerek oluşturun, böylece karışmaz.
2. İlerleme göstergesini kaldırmak için -s bayrağını ekleyin.
3. Gerekli zaman değişkenleriyle -w bayrağını ekleyin.
4. Komutu proxy'niz aracılığıyla ihtiyaç duyduğunuz sayıda döngüde çalıştırın.
5. Tüm TTFB değerlerini bir dosyaya, her satıra bir sayı olacak şekilde kaydedin.

Yüzdelik Dilimler Nasıl Hesaplanır

Toplanan sayıları artan sırayla sıralayın. Listenin ortasındaki konumdaki değer p50'dir. Listenin uzunluğunun yüzde doksan beşindeki konumdaki değer p95'tir. Yüzde doksan dokuzdaki konumdaki değer p99'dur. Kılavuzun sonundaki Python scriptinde bu otomatik olarak yapılır.

İpucu: Her zaman p50 ve p95'i birlikte inceleyin. Yakınlarsa proxy istikrarlıdır. Aralarında uçurum varsa proxy'de nadir ama acı verici düşüşler vardır.

Olası Sorunlar

• TTFB değerleri şüpheli derecede küçük. Önbellek devreye girmiş olabilir. Keep-alive bağlantılarını devre dışı bırakan bayrağı kullanarak yeniden kullanımı kapatın ve adrese benzersiz bir parametre ekleyin.
• Değerler çalıştırmalar arasında büyük farklılık gösteriyor. Bu mobil ağ için normaldir. Bu yüzden tek seferlik değil seriler halinde ölçüm yapıyoruz.

✅ Kontrol: TTFB değerlerini içeren bir dosyanız ve gerçek gecikme davranışını tanımlayan üç yüzdelik dilim sayınız var.

Adım 3: Bant Genişliğini Dürüstçe Ölçme

Bu aşamanın amacı: Kendi kendini kandırmadan gerçek veri aktarım hızını öğrenmek.

Dürüstçe Nasıl Ölçülür

Proxy üzerinden bilinen boyutta bir dosya indirin ve bunun ne kadar sürdüğünü ölçün. Boyutu süreye bölün ve hızı elde edin. Kulağa basit geliyor, ancak kolayca gözden kaçırılan nüanslar var.

1. Gerçek kaynaklardan farklı boyutlarda birkaç dosya seçin.
2. Her birini curl ile proxy üzerinden indirin, zamanı -w bayrağıyla time_total değişkeni ve size_download değişkeni ile ölçün.
3. Her dosya için indirme işlemini birkaç kez tekrarlayın.
4. Her çalıştırma için hızı hesaplayın ve dağılıma bakın.

Neden Birden Fazla Dosya ve Uç Nokta

Tek bir sunucudaki tek bir dosya, sunucunun kendi sınırlamasına takılabilir, proxy'nize değil. Farklı kaynaklar farklı bir tablo çizer. Tüm kaynaklarda hız benzer şekilde düşükse sorun proxy'dedir. Farklılık gösteriyorsa darboğaz belirli bir sunucuda olabilir.

Tarife Kısıtlamalarının Etkisi

Birçok mobil tarifenin hız veya veri hacmi sınırlamaları vardır. Belirli bir eşikten sonra hız keskin bir şekilde düşebilir. Bunu göz önünde bulundurun: arka arkaya çok fazla veri indirdiyseniz yavaşlama, proxy kalitesinden değil tarifeden kaynaklanıyor olabilir.

⚠️ Dikkat: Tarifeniz sınırlıysa test amacıyla devasa veri hacimleri indirmeyin. Veri paketinizi tüketme riskiniz vardır. Orta boyutta dosyalar kullanın.

İpucu: Bant genişliğini diğer metriklerle aynı gün saatinde ölçün. Ağ yükü sonucu büyük ölçüde etkiler.

Olası Sorunlar

• Hız dengesiz. Bu mobil ağlar için tipiktir. Tek bir en iyi sonuca değil, hızın medyanına bakın.
• Test sırasında hız keskin bir şekilde düştü. Tarife limiti devreye girmiş veya ağ modu değişmiş olabilir.

✅ Kontrol: Birden fazla kaynağa göre hız değerleriniz ve darboğazın nerede olduğuna dair bir anlayışınız var.

Adım 4: Jitter ve İstikrarı Ölçme

Bu aşamanın amacı: Proxy'nin ne kadar hızlı olduğundan çok ne kadar düzgün çalıştığını anlamak.

Ne yapıyoruz

Önceki adımlardan gecikme ölçüm serisini alıyor ve dağılıma bakıyoruz. Jitter, temelde komşu değerlerin birbirinden ne kadar farklı olduğunun bir ölçüsüdür.

1. İkinci adımda toplanan gecikme değerlerini içeren dosyayı alın.

2. Komşu ölçümler arasındaki farkı hesaplayın.
3. Bu farkların mutlak değerlerinin ortalamasını alın - bu jitter tahminidir.
4. Ek olarak tüm serinin standart sapmasına bakın.

Normal Olarak Ne Kabul Edilir

Evrensel belirli sayılar yoktur çünkü normal, göreve bağlıdır. Genel prensip şudur: jitter, gecikmenin kendisine göre ne kadar küçükse o kadar iyidir. Gecikme yüz milisaniye ve jitter beş ise bu mükemmeldir. Jitter gecikmeyle karşılaştırılabilir düzeydeyse çalışma dengesiz olacaktır.

İpucu: Ölçüm serisini basit bir grafikle görselleştirin. Düz bir çizgi iyi işarettir. Keskin dişleri olan bir testere endişe vericidir.

Değerlerdeki Dağılım

Nadir görülen aykırı değerlere dikkat edin. Yüz istekte bir keskin sıçrama tolere edilebilir. Düzenli sıçramalar, proxy'nin mobil ağ dalgalanmalarından normalden daha fazla etkilendiği anlamına gelir.

✅ Kontrol: Jitter tahmininiz ve proxy'nin istikrarlı olup olmadığına dair bir anlayışınız var.

Adım 5: IP Değişimindeki Davranışı Kontrol Etme

Bu aşamanın amacı: Proxy'nin IP adresini ne kadar hızlı ve ne kadar kaliteli değiştirdiğini anlamak.

Neyi ölçüyoruz

Mobil proxy'ler, istek üzerine veya zamanlamalı olarak IP adresini değiştirebilir. Birkaç şeyle ilgileniyoruz: değişimin ne kadar sürdüğü, yeni adresin aynı ağ ve şehirde kalıp kalmadığı ve bir saat içinde kaç benzersiz adres toplandığı.

1. IP kontrol uç noktası aracılığıyla geçerli IP adresini isteyin.
2. Tedarikçinizin sağladığı şekilde IP değişimini başlatın.
3. Yeni adresin kullanılabilir hale gelmesine kadar geçen süreyi ölçün.
4. IP'yi tekrar isteyin ve kaydedin.
5. Döngüyü bir saat içinde birçok kez tekrarlayın.
6. Benzersiz adres sayısını ve her değişimin süresini hesaplayın.

Sonuç Nasıl Değerlendirilir

Birkaç parametreye bakın. Değişim hızı, ne kadar hızlı yeni bir adres aldığınızı gösterir. Bir saat içindeki benzersiz adres sayısı, havuzun çeşitliliğini gösterir. Aynı ağ ve şehre ait olmak, beklenen segmentte kaldığınızı doğrular.

İpucu: Yalnızca adresi değil, kontrol uç noktasının döndürdüğü ağ ve şehir bilgilerini de kaydedin. Böylece değişimde coğrafyanın istikrarlı olup olmadığını görürsünüz.

⚠️ Dikkat: IP değişimini yalnızca yasal amaçlarla ve çalıştığınız hizmetlerin kuralları dahilinde kullanın. Proxy'nin teknik yetenekleri, yasal gereklilikleri ve kullanıcı sözleşmelerini geçersiz kılmaz.

Olası Sorunlar

• Değişim çok uzun sürüyor. Doğru yöntemi kullanıp kullanmadığınızı kontrol edin. Tedarikçinize standart yöntemi sorun.
• Adresler tekrarlanıyor. Küçük tekrarlar olabilir, ancak sürekli kopyalar küçük bir havuz olduğunu gösterir.

✅ Kontrol: Değişim süresi, bir saat içindeki benzersiz adres sayısı ve coğrafi bilgileri hakkında verileriniz var.

Adım 6: Coğrafya ve Bağlantı Türü Uyumunu Kontrol Etme

Bu aşamanın amacı: Proxy'nin gerçekten beyan edilen özelliklere uygun olduğundan emin olmak.

Neyi kontrol ediyoruz

Tedarikçi genellikle ülke, bölge ve bağlantı türünü (örneğin mobil ağ) belirtir. Görevimiz, beyan edilen ile gerçek olanı karşılaştırmaktır.

1. Proxy üzerinden adresinizle ilgili verileri döndüren bir uç noktaya erişin.
2. Belirlenen ülke ve bölgeyi kaydedin.
3. Hizmetin belirlediği bağlantı türünü kaydedin.
4. Kontrolü farklı IP adreslerinde birkaç kez tekrarlayın.
5. Sonuçları tedarikçinin vaat ettiğiyle karşılaştırın.

Sonuç Nasıl Okunur

Coğrafya ve bağlantı türü sürekli olarak beyan edilenle eşleşiyorsa harika. Ara sıra başka bölgeler çıkıyorsa veya bağlantı türü uyuşmuyorsa, bu tedarikçiye soru sormak için bir nedendir.

İpucu: Coğrafyayı birden fazla bağımsız kaynaktan kontrol edin. IP adresi veritabanları bazen farklılık gösterir ve tek bir kaynak hatalı olabilir.

✅ Kontrol: Coğrafya ve bağlantı türünün beyan edilenle uyumunu doğruladınız veya reddettiniz.

Adım 7: 24 Saatlik Uzun Süreli Test Çalıştırma

Bu aşamanın amacı: Beş dakikada fark edilemeyen şeyleri görmek.

Neden 24 Saatlik Test Gerekli

Kısa bir test yalnızca ağın mevcut durumunu yakalar. 24 saatlik test, proxy'nin farklı zamanlardaki davranışını gösterir: sabah, öğle yoğunluğu, gece. Gecikmenin, başarılı yanıt oranının ve istikrarın gün içinde nasıl değiştiğini görürsünüz.

1. Script'i periyodik ölçümler yapacak şekilde ayarlayın, örneğin her birkaç dakikada bir.
2. Arka planda çalıştırın ve 24 saat boyunca çalışmasına izin verin.
3. Sonuçların zaman damgasıyla bir dosyaya yazıldığından emin olun.
4. 24 saat sonra verileri toplayın ve saat bazında bir tablo oluşturun.

Uzun Süreli Test Ne Gösterir

Mobil ağın aşırı yüklendiği yoğun saatlerdeki düşüşleri görürsünüz. Geceleri istikrar pencerelerini fark edersiniz. Beş dakikada ortaya çıkmayacak nadir hata artışlarını keşfedersiniz. İyi bir proxy'yi vasat olandan ayıran şey tam da 24 saatlik testtir.

⚠️ Dikkat: 24 saatlik testte veri kullanımını izleyin. Tarife limitinizi bir gün içinde tüketmemek için hafif istekler yapın.

İpucu: Uyku moduna geçebilecek bir bilgisayarda 24 saatlik test çalıştırmayın. Uyku modunu kapatın, aksi takdirde ölçümler kesintiye uğrar.

✅ Kontrol: Proxy'nin dinamik davranışını gösteren, zaman damgalı 24 saatlik bir logunuz var.

Ölçümler İçin Hazır Scriptler

Aşağıda açıklanan metrikleri hesaplayan taslaklar verilmiştir. Bunları kendi erişim bilgilerinize ve uç noktalarınıza uyarlayın.

Bash Scripti

Bu script bir dizi istek yapar, TTFB ve yanıt kodlarını toplar ve bir dosyaya kaydeder. Mantık şöyledir: döngüde proxy üzerinden curl çalıştırılır, -w bayrağı ilk bayt süresini ve yanıt kodunu gösterir, sonuç loga eklenir.

Script'in ana öğeleri: protokol, kullanıcı adı, şifre, adres ve port formatında proxy adresini içeren değişken. Hedef uç noktayı içeren değişken. Belirtilen sayıda tekrar için döngü. Döngü içinde -s (sessiz), -o (gövdeyi at), --max-time (bekleme sınırı) ve -w (time_starttransfer ve http_code değişkenleriyle) bayraklarıyla curl çağrısı. Sonucun her satırı bir metin dosyasına eklenir. Döngüden sonra bash basit istatistikler hesaplayabilir veya dosyayı Python'a aktarabilir.

Önbelleği devre dışı bırakmak için adrese benzersiz bir sorgu parametresi ekleyin ve bağlantı yeniden kullanımını devre dışı bırakan bayrağı kullanın. Bu, her ölçümün hafızadan alınmadığından emin olmanızı sağlar.

Python Scripti

Python scripti, yüzdelik dilimleri ve jitter'ı hesaplamak için daha kullanışlıdır. Değerleri içeren bir dosyayı okur veya proxy'yi destekleyen bir HTTP kütüphanesi aracılığıyla istekleri kendisi yapar.

Script'in mantığı şöyledir. Önce parametreler ayarlanır: proxy adresi, uç nokta listesi, tekrar sayısı ve zaman aşımı. Ardından bir döngüde istekler yürütülür, her biri için ilk bayt süresi, toplam süre ve yanıt kodu kaydedilir. Başarılı ve başarısız yanıtlar ayrı ayrı sayılır. Tüm gecikme değerleri bir listeye eklenir.

Veriler toplandıktan sonra script, gecikme listesini sıralar ve yüzdelik dilimleri hesaplar. Medyan, sıralanan listenin ortasından alınır. p95, listenin uzunluğunun yüzde doksan beşindeki konumdan alınır. p99, yüzde doksan dokuzdaki konumdan alınır. Jitter, komşu ölçümler arasındaki farkların mutlak değerlerinin ortalaması olarak hesaplanır. Başarılı yanıt oranı, başarılı sayısının toplam istek sayısına bölünmesidir.

Script sonunda bir özet rapor yazdırır: başarılı yanıt oranı, gecikme yüzdelik dilimleri, jitter tahmini ve hata türlerine göre dağılım. 24 saatlik test için her kayda bir zaman damgası ekleyin ve ölçümleri seriler arasında duraklamalı bir döngüye sarın.

İpucu: Yalnızca nihai sayıları değil, ham verileri de kaydedin. Daha sonra metriği farklı şekilde yeniden hesaplamanız gerekirse kaynaklarınız olsun.

⚠️ Dikkat: Proxy kullanıcı adı ve şifresini, yanlışlıkla birine gösterebileceğiniz script'in içine değil, ayrı bir yapılandırma dosyasında saklayın.

Sonuçlar Tek Bir Tabloda Nasıl Toplanır

Verileri topladığınızda bunları görsel olarak sunmak önemlidir. Tek bir tablo, tedarikçileri dürüstçe karşılaştırmanıza olanak tanır.

Sonuç Tablosunun Yapısı

Satırlar metrikler, sütunlar tedarikçiler olacak şekilde bir tablo yapın. Her metrik için değeri ve uygun olduğunda yüzdelik dilimleri belirtin. Böylece kimin hangi alanda daha güçlü olduğunu hemen görürsünüz.

• Başarılı yanıt oranı - her tedarikçi için yüzde.
• TTFB - üç sayı: p50, p95, p99.
• Bant genişliği - hızın medyanı.
• Jitter - dağılım tahmini.
• IP değişimi - değişim süresi ve bir saat içindeki benzersiz adres sayısı.
• Coğrafya ve bağlantı türü - beyan edilenle eşleşiyor mu?
• 24 saatlik davranış - yoğun saatlerde düşüş var mı?

Metrik Yorumlama Tablosu

Metrik, nasıl ölçüldüğü, kötü değerin ne anlama geldiği şeklinde sözlü bir tablo verelim. Belirli sayılar uydurmuyoruz - normlar göreve bağlıdır.

• Başarılı yanıt oranı. Bir dizi istekle ölçülür ve başarılar sayılır. Kötü değer: özellikle kopmalar olmak üzere kayda değer miktarda hata, güvenilmezlik anlamına gelir.
• TTFB ve yüzdelik dilimler. Büyük bir seride curl ile ilk bayt süresi değişkeni kullanılarak ölçülür. Kötü değer: p50 ve p99 arasında büyük uçurum, nadir ama acı verici düşüşler anlamına gelir.
• Bant genişliği. Bilinen boyuttaki dosyaları indirerek ölçülür. Kötü değer: görevlerinizi karşılamayan veya keskin bir şekilde düşen hız.
• Jitter. Komşu gecikmelerin dağılımı olarak ölçülür. Kötü değer: jitter'ın gecikmenin kendisiyle karşılaştırılabilir olması, dengesiz çalışma anlamına gelir.
• IP değişimi. Değişim süresinin ölçüldüğü bir döngü ile ölçülür. Kötü değer: uzun değişim süresi ve az sayıda benzersiz adres.
• Coğrafya ve bağlantı türü. Tanımlama uç noktasıyla karşılaştırılarak ölçülür. Kötü değer: beyan edilenle uyuşmazlık.
• 24 saatlik istikrar. Uzun süreli testle ölçülür. Kötü değer: yoğun saatlerde metriklerde güçlü düşüşler.

İpucu: Karşılaştırma yaparken tek bir satırdan sonuç çıkarmayın. Metrikleri tam olarak sizin göreviniz için önemlerine göre tartın. Kimisi için istikrar kritiktir, kimisi için adres değişim hızı.

Sonucu Kontrol Etme: Ölçüm Kalitesi Kontrol Listesi

Rakamlarınıza güvenmeden önce listeyi gözden geçirin. Bu, ölçümlerin doğru olduğunu garanti eder.

• Her metrik tek bir istekle değil, bir seriyle ölçüldü.
• Her iki tedarikçi de aynı gün saatinde test edildi.
• Aynı uç noktalar ve zaman aşımları kullanıldı.
• Gecikme için yalnızca ortalama değil, yüzdelik dilimler hesaplandı.
• Gerektiğinde önbellek ve bağlantı yeniden kullanımı devre dışı bırakıldı.
• Test, yalnızca hız testi sunucularında değil, gerçek hedeflerde yapıldı.
• En az bir 24 saatlik test yapıldı.
• Yeniden hesaplama gerektiğinde ham veriler kaydedildi.

✅ Kontrol: Tüm maddeler işaretliyse sonuçlarınız karar vermek için güvenilir bir temel oluşturur.

Tipik Ölçüm Hataları ve Çözümleri

Burada en sık yapılan hatalar toplanmıştır. Her biri sorun, neden ve çözüm olarak açıklanmıştır.

Hata Bir: Tek Seferlik Test

Sorun: Bir-iki istekten sonuç çıkarılmış. Neden: Hızlı bir rakam alma isteği. Çözüm: Her zaman düzinelerce veya yüzlerce istekten oluşan bir seri yapın ve dağılıma bakın.

Hata İki: Yalnızca Yoğun Saatte Test

Sorun: Sonuçlar ya korkunç ya da mükemmel görünür. Neden: Ölçüm, ağın en yoğun veya en düşük yükü anında yapılmıştır. Çözüm: Farklı zamanlarda ölçün ve mutlaka 24 saatlik test yapın.

Hata Üç: Hız Testi Sunucularına Ölçüm

Sorun: Rakamlar güzel, ancak gerçek işte her şey farklı. Neden: Özel hız testi sunucuları gerçek hedefleri yansıtmaz. Çözüm: Çalışacağınız kaynaklar üzerinde test yapın.

Hata Dört: Önbelleği Görmezden Gelme

Sorun: Gecikme şüpheli derecede düşük ve istikrarlı. Neden: Yanıtlar ağdan değil önbellekten geliyor. Çözüm: Adrese benzersiz bir parametre ekleyin ve önbelleğe almayı devre dışı bırakın.

Hata Beş: Keep-Alive Tabloyu Bozar

Sorun: İlk istek yavaş, sonrakiler anlık. Neden: Bağlantı yeniden kullanılır ve tekrarlanan ölçümler bağlantı kurma süresini hesaba katmaz. Çözüm: Dürüst ölçüm için tam gecikmeyi görmek istiyorsanız bağlantı yeniden kullanımını devre dışı bırakın.

Hata Altı: Yüzdelik Dilimler Yerine Ortalamayı Karşılaştırma

Sorun: İki proxy ortalamada aynı görünür, ancak pratikte biri belirgin şekilde kötüdür. Neden: Ortalama düşüşleri gizler. Çözüm: p95 ve p99'u karşılaştırın.

Hata Yedi: Farklı Tedarikçiler İçin Farklı Koşullar

Sorun: Karşılaştırma adil değildir. Neden: Bir proxy gündüz bir uç noktada, diğeri gece başka bir uç noktada test edilmiştir. Çözüm: Tek tip protokole sıkı sıkıya bağlı kalın.

Ek Olanaklar ve Optimizasyon

Temel yöntemi öğrendikten sonra derinleşebilirsiniz.

Düzenli Kontrollerin Otomasyonu

Script'i günlük olarak çalışacak şekilde zamanlayın. Böylece proxy'nin zamanla bozulup bozulmadığını görebilirsiniz. Geçmişi biriktirin ve eğilim çizin.

Paralel Ölçümler

İleri düzey kullanıcılar, yük altındaki davranışı değerlendirmek için aynı anda birden çok iş parçacığı çalıştırabilir. Bunu dikkatli bir şekilde ve tedarikçinin kuralları dahilinde yapın.

Veri Görselleştirmesi

Toplanan verilerden grafikler oluşturun. Günün saatine göre gecikme grafiği, yoğun saatleri net bir şekilde gösterir. Gecikme dağılımının histogramı, yavaş yanıtların uzun kuyruğu olup olmadığını gösterir.

İpucu: Elektronik tabloda basit bir grafik bile sonuçları bir sayı sütunundan çok daha ikna edici hale getirir.

Uç Noktalara Göre Segmentasyon

Metrikleri her uç nokta için ayrı ayrı hesaplayın. Bazen proxy bazı hedeflerde mükemmel, bazılarında daha kötü çalışır. Bu ayrıntı, nokta atışı kararlar almanıza yardımcı olur.

SSS: Proxy Kalitesini Ölçme Hakkında Sıkça Sorulan Sorular

Güvenilir bir sonuç için kaç istek gerekir?

Ne kadar çok olursa o kadar iyidir. Minimum anlamlı seri birkaç düzinedir. Önemli bir karar için yüzlerce istek ve mutlaka 24 saatlik test yapın.

Neden reklamdaki hız rakamına güvenemeyiz?

Çünkü hız, yedi metrikten yalnızca bir tanesidir. Proxy hızlı olabilir, ancak dengesiz, düşük erişilebilirlik veya yavaş IP değişimi olabilir. Reklam en iyi durumu gösterir, tipik durumu değil.

Hangisi daha önemli: gecikme mi yoksa bant genişliği mi?

Göreve bağlıdır. Hızlı, hafif istekler için gecikme ve istikrar daha önemlidir. Büyük hacimli veri aktarımı için bant genişliği daha önemlidir. Metriklerin bütününe bakın.

Ortalama gecikme değeri neden yanıltıcıdır?

Çünkü nadir görülen büyük değerler ortalamayı şişirir, nadir küçük değerler düşürür. p50, p95 ve p99 yüzdelik dilimleri dağılımı dürüstçe tanımlar ve en kötü durumların nasıl davrandığını gösterir.

Proxy'nin dengesiz olduğunu, sadece yavaş olmadığını nasıl anlarız?

Jitter'a ve yüzdelik dilimler arasındaki uçuruma bakın. Yavaş proxy istikrarlı bir şekilde büyük ama düzgün değerler verir. Dengesiz olan mükemmelden berbat arasında gidip gelir.

Ölçümler sırasında önbelleği devre dışı bırakmak zorunlu mu?

Gecikmeyi dürüstçe ölçmek için evet. Aksi takdirde ağ hızı yerine bellek hızını ölçersiniz. Adrese benzersiz bir parametre ekleyin ve bağlantı yeniden kullanımını devre dışı bırakın.

Beş dakikalık test bir şey gösterdiyse neden 24 saatlik teste ihtiyaç var?

Beş dakikalık test anı yakalar. 24 saatlik test, yoğun saatlerde, gece ve sabah davranışını gösterir, nadir hata artışlarını ortaya çıkarır. Yalnızca bu test, güvenilir bir proxy'yi şans eseri iyi olandan ayırır.

İki tedarikçiyi farklı zamanlarda test ederek karşılaştırabilir miyim?

Hayır. Ağ gün içinde değişir ve karşılaştırma adil olmaz. Her ikisini de aynı zaman aralığında, tek tip protokole göre test edin.

Sonuçlar çalıştırmadan çalıştırmaya çok dalgalanıyorsa ne yapmalıyım?

Bu mobil ağlar için normaldir. Bu nedenle tek seferlik ölçümlere değil, serilere ve yüzdelik dilimlere güveniyoruz. Deneme sayısını artırın.

IP değişimini kullanmayı planlamıyorsam test etmeli miyim?

İşlev sizin için önemli değilse bu adımı atlayabilirsiniz. Ancak hızlıca ölçmek, adres havuzunun kalitesi hakkında genel bir anlayış için faydalıdır.

Sonuç: Reklam Rakamlarından Kendi Ölçümlerinize

Tek bir hız rakamına safça inanmaktan, sistematik bir değerlendirme yöntemine kadar bir yol kat ettiniz. Artık yedi metriğiniz, tek tip bir protokolünüz, hazır scriptleriniz ve sonuçları nasıl okuyacağınıza dair bir anlayışınız var.

Ne öğrendiniz. Başarılı yanıt oranını, gecikmeyi yüzdelik dilimlerle, bant genişliğini, jitter'ı, IP değişimindeki davranışı, coğrafya uyumunu ve 24 saatlik istikrarı ölçmeyi öğrendiniz. Ortalamanın neden yanılttığını ve tek bir testin hiçbir şey kanıtlamadığını biliyorsunuz.

Bundan sonra ne yapmalısınız. Yöntemi mevcut proxy'nize uygulayın ve temel sayıları kaydedin. Ardından alternatif bir tedarikçiyi aynı protokole göre test edin ve tek bir tabloda karşılaştırın. Karar netleşecektir.

Nereye gelişebilirsiniz. Düzenli kontrolleri otomatikleştirin, geçmiş biriktirin ve grafikler oluşturun. Zamanla, bozulma işinizi etkilemeden önce fark edeceksiniz. Ana kuralı unutmayın: reklamlara değil, dürüst ve sistematik bir şekilde yaptığınız kendi ölçümlerinize güvenin. Kendine güvenen bir kullanıcıyı, körü körüne ödeyenden ayıran şey tam da budur.