Proxy Thread Sayısı Nasıl Belirlenir? Eşzamanlılık Planı

Thread, eşzamanlı bağlantı ve istek/saniye aynı şey değildir

Üç terim günlük konuşmada birbirinin yerine kullanılır, ama proxy planlamasında üçü ayrı ayrı ölçülür. Thread, istemci programınızın aynı anda yürüttüğü iş parçacığı sayısıdır. Eşzamanlı bağlantı, o anda açık duran TCP bağlantısı sayısıdır. İstek/saniye ise birim zamanda tamamlanan istek sayısıdır. Bir thread birden fazla bağlantı tutabilir; asenkron bir istemci tek thread ile yüzlerce bağlantı açabilir. Tersine, bir thread bağlantı havuzundan sırayla bağlantı alıp bırakıyorsa on thread, on bağlantıdan azına denk gelebilir.

Proxy sağlayıcısı ve hedef, bağlantı sayısını ve istek hızını görür; thread sayısını görmez. Bu yüzden plan, thread sayısından başlamaz. Önce hedefe saniyede kaç istek göndermek istediğinize karar verirsiniz, sonra bir isteğin ortalama kaç saniye sürdüğünü ölçersiniz; ikisinin çarpımı gereken eşzamanlı bağlantı sayısıdır. Thread sayısı bu bağlantı sayısını taşıyacak kadar olur.

Varsayım olarak hedefe saniyede 10 istek göndermek istiyorsunuz ve bir istek proxy üzerinden ortalama 0,8 saniye sürüyor. Gereken eşzamanlı bağlantı 10 × 0,8 = 8’dir. Aynı hızda ama 2 saniye süren bir hedefte sayı 20’ye çıkar. Gecikme arttıkça aynı hız için daha fazla bağlantı gerekir; bu da proxy lokasyonunun eşzamanlılık planını doğrudan etkilediği anlamına gelir. Gecikmeyi bileşenlerine ayırarak ölçme yöntemi proxy gecikme ölçümü rehberinde anlatılıyor.

Bir tarayıcı sayfası neden tek bağlantı değildir?

HTTP istemcisiyle bir URL çekmek tek istektir. Aynı sayfayı başsız (headless) tarayıcıyla açmak ise onlarca istektir: HTML’den sonra stil dosyaları, betikler, görseller, yazı tipleri ve sayfanın kendi çağırdığı API uçları gelir. Tarayıcı bunları paralel bağlantılarla indirir ve her biri proxy üzerinden geçer. Sağlayıcı tarafında aynı anda açılan altı ya da daha fazla bağlantı görülür.

Bu fark eşzamanlılık planını iki yerde değiştirir. Birincisi bağlantı sayısı: beş tarayıcı sekmesi otuz ile elli arası bağlantıya denk gelebilir; port ya da bağlantı sınırı olan bir üründe bu sınır beklenenden çok önce dolar. İkincisi aktarılan veri: HTML tek başına birkaç yüz kilobayt iken sayfanın tamamı megabaytlara çıkar ve GB bazlı üründe kota aynı sayfa sayısı için birkaç kat hızlı erir.

Tarayıcı kullanmak zorundaysanız gereksiz kaynak türlerini engelleyin (görsel, yazı tipi, izleme betikleri) ve sekme başına ortalama bağlantı sayısını bir kez ölçün. Ölçüm basittir: tek sekme açıkken proxy logunda ya da istemcinin ağ panelinde aynı saniyede açık bağlantı sayısını sayın. Bu sayı, sekme sayısıyla çarpılarak toplam eşzamanlı bağlantı tahminine dönüşür.

Sınırı kim koyar? Üç taraf, üç farklı belirti

Birinci taraf proxy ürünüdür. Port bazlı üründe her port kendi bağlantı kapasitesine sahiptir ve bu kapasite ürün tanımında yazar; yazmıyorsa satın almadan önce desteğe sorun, tahmin etmeyin. Adet bazlı static üründe her IP ayrı bir çıkış olduğu için sınır genellikle IP başına değil, toplam bağlantı davranışınıza göre değerlendirilir. Sağlayıcı sınırına çarptığınızda belirti, bağlantının proxy tarafında reddedilmesi ya da kuyrukta beklemesidir: hedefe hiç ulaşmayan, proxy katmanında zaman aşımına düşen istekler görürsünüz.

İkinci taraf hedef sunucudur. Her hedefin belirli bir adresten ve toplamda kabul ettiği bir hız vardır; bunu robots dosyasındaki tarama aralığı, API dokümanındaki hız sınırı ya da kullanım koşulları açıkça söyleyebilir. Söylemiyorsa hedefin verdiği 429 ve yavaşlayan yanıt süreleri sınırın ölçüsüdür. Hedef sınırına çarptığınızda belirti, isteğin hedefe ulaşıp 429 ya da 503 ile dönmesi veya aynı eşzamanlılıkta ilk bayt süresinin katlanmasıdır. Bu belirti hızı düşürmekle çözülür; hedefin koyduğu sınır bir kuraldır ve proxy sayısını artırarak aşılmaz.

Üçüncü taraf kendi makinenizdir. Her açık bağlantı bellek, bir dosya tanımlayıcısı ve bir kaynak portu tüketir; TLS el sıkışması işlemci ister. Bin eşzamanlı bağlantıyı küçük bir sanal sunucuda açmak, proxy ve hedef sorunsuz olsa bile istemci tarafında hata üretir. Belirtisi işletim sistemi hatalarıdır: açık dosya sınırı, atanamayan adres, bellek baskısıyla yavaşlayan süreç. Bu sınırların her birinin kendi çözümü vardır ve ayrı bir yazının konusudur; burada yalnız tanınması önemlidir.

Üç tarafı ayırmanın en kısa yolu hatanın nerede doğduğuna bakmaktır. Proxy katmanında reddedilen istek sağlayıcı sınırı, hedeften 429 ile dönen istek hedef sınırı, istemcide soket açılamadan düşen istek makine sınırıdır. Üçü aynı anda da görülebilir; o zaman önce makine, sonra sağlayıcı, en son hedef sınırı ele alınır, çünkü ilk ikisi ölçümü bozar.

Küçükten başlayıp artırma: hata oranı ve gecikmeyi izleyerek

Thread sayısını baştan büyük seçip hata gelince düşürmek, hedefte iz bırakır ve ölçümü bozar. Doğru yön tersidir: küçük bir değerle başlayıp iki ölçüt sabit kaldığı sürece kademeli artırmak. Ölçütler hata oranı (4xx ve 5xx dışındaki ağ hataları dahil, toplam isteğe oranı) ve ilk bayt süresinin medyanıdır.

Yöntem beş adımdır. Bir: Eşzamanlılığı yukarıdaki hesabın yarısından başlatın; örnekte 8 çıktıysa 4 ile başlayın. İki: Her kademede en az beş dakika ya da bin istek koşun; daha kısa pencere dalgalanmayı kural sanmanıza yol açar. Üç: Kademe sonunda hata oranı ve medyan süreyi önceki kademeyle karşılaştırın. Dört: İkisi de sabitse eşzamanlılığı yüzde elli artırın (4, 6, 9, 13…); medyan süre belirgin yükseldiyse ya da hata oranı arttıysa önceki kademeye dönün. Beş: Bulduğunuz değerin yüzde seksenini üretim ayarı yapın; kalan pay hedefin yoğun saatleri içindir.

Medyan sürenin eşzamanlılıkla birlikte yükselmesi, hızın artık artmadığının işaretidir: aynı istek/saniye değerine daha fazla bağlantıyla ulaşıyorsunuzdur ve her bağlantı kuyrukta bekliyordur. Bu noktadan sonra thread eklemek hız getirmez, yalnız hedef üzerindeki baskıyı ve kendi kaynak kullanımınızı artırır. Hata oranındaki artış ise daha erken bir uyarıdır ve her zaman geri adım gerektirir.

Bu deneyi hedef başına ayrı yapın. Aynı eşzamanlılık değeri bir hedefte rahat, diğerinde fazla olabilir. Birden çok hedefi aynı işte tarıyorsanız hedef başına ayrı eşzamanlılık kotası tutan bir yapı kurun; toplam thread sayısı bu kotaların toplamıdır.

Static IP adedi mi, rotating port mu? Eşzamanlılığa göre ürün seçimi

DatacenterProxy kataloğunda eşzamanlılık üç farklı birimle karşınıza çıkar. Static IPv4 datacenter adet bazlıdır: 100, 250, 500 ve 1.000 IP paketleri 30 günlük dönemde 15, 25, 45 ve 80 USD. Rotating IPv4 datacenter GB bazlıdır: 2, 10, 20, 50 ve 100 GB paketleri 1, 6, 12, 30 ve 60 USD; eşzamanlı bağlantı sayısı doğrudan fiyatlanmaz, aktarılan veri fiyatlanır. Rotating IPv6 datacenter port bazlıdır: 1, 5 ve 10 port aylık 29, 80 ve 175 USD; ürün sayfası port sayısını eşzamanlı bağlantı ihtiyacına göre seçmenizi söyler.

Static adet modeli, eşzamanlı bağlantıları birçok sabit çıkışa dağıtmak isteyen işler içindir: her IP kendi bağlantı havuzunu taşır, tek bir IP’nin arızası diğerlerini etkilemez ve hedefin her adresten gördüğü hız düşük kalır. IP sayısı bağlantı havuzunu dağıtmak ve yedeklilik sağlamak için artırılır; hedefin koyduğu sınırı aşmak için kullanılmaz ve toplam hız yine hedefin kabul ettiği bütçenin içinde kalmalıdır. Kaç IP gerektiği, hedef sayısı ve IP başına bağlantı havuzu büyüklüğünden çıkar; maliyet tarafı datacenter proxy maliyet hesaplama rehberinde çalışma kâğıdıyla anlatılıyor.

Rotating GB modeli, eşzamanlılığın ikincil olduğu işler içindir: istek sayısı yüksek, her isteğin çıkışı farklı, veri miktarı belirleyici. Eşzamanlılığı istemci tarafında yukarıdaki yöntemle bulursunuz; ürün tarafında bir port sayısı seçmeniz gerekmez. Rotating port modeli ise IPv6 kabul eden hedeflerde, bağlantı kapasitesini aylık sabit bir birimle almak isteyen işler içindir. Port başına kaç bağlantı taşınabildiği ürün tanımında yazmıyorsa destekten sorun; bir rakibin tablosundaki sayı sizin ürününüz için geçerli değildir.

Paylaşımlı ve özel havuz farkı da eşzamanlılığı etkiler: paylaşımlı adreste aynı IP’den başka müşterilerin bağlantıları da geçer ve hedefin o adresten gördüğü toplam hız sizin kontrolünüzde değildir. Bu konu dedicated ve shared datacenter proxy rehberinde ayrıca ele alınıyor.

Kontrol listesi: thread sayısı yayına girmeden önce

Hedeflenen istek/saniye değeri yazılı mı ve hedefin açıkladığı bir sınırın (robots aralığı, API limiti, kullanım koşulları) altında mı?

Ortalama istek süresi aynı hedefte, aynı proxy lokasyonunda, en az on tekrarla ölçüldü mü?

Eşzamanlı bağlantı sayısı hesapla bulundu, thread sayısı buna göre seçildi mi (asenkron istemcide thread sayısı bağlantı sayısından küçük olabilir)?

Tarayıcı kullanılıyorsa sekme başına bağlantı sayısı ölçüldü ve gereksiz kaynak türleri engellendi mi?

Kademeli artırma deneyi yapıldı, üretim değeri bulunan eşiğin yüzde sekseni olarak ayarlandı mı?

Hata oranı ve medyan süre üretimde izleniyor, eşik aşımında eşzamanlılığı otomatik düşüren bir kural var mı?

Ürün birimi (adet, GB, port) eşzamanlılık ihtiyacına göre seçildi; port kapasitesi ürün tanımından ya da destekten doğrulandı mı?

Birden çok hedef varsa hedef başına ayrı eşzamanlılık kotası tutuluyor mu?