İstek Başına Proxy Ücretlendirmesi

Ne için ödeme yaparsınız?

Sağlayıcının saydığı istek adedi için ödeme yaparsınız. Sağlayıcı sabit paketler satabilir veya hizmeti kullandıkça ücretlendirebilir. Fiyatlar çoğu zaman bin veya milyon istek başına verilir. Bu, tarifeleri karşılaştırmayı kolaylaştırır, ancak ödeme adımında ne kadar harcamanız gerektiğini söylemez: en küçük paket daha fazla istek içerebilir.

Aynı “istek” sözcüğü farklı hizmetleri tanımlayabilir. Olağan proxy sunucusu, uygulamanızın isteklerini web sitelerine iletir ve yanıtlarını geri döndürür. Sayfaları uygulamanız yükler ve verileri çıkarır. Veri toplama API’sinde fiyata tarayıcı çalıştırma, erişim kısıtlamalarını ele alma ve sonuçları hazırlama da dahil olabilir. Bu nedenle yalnızca istek fiyatını karşılaştırmak yetmez; hizmetin bu fiyat karşılığında ne yaptığını bilmeniz gerekir.

Bu ücretlendirme, belirli takvime uyan işler için kullanışlıdır. Kaç sayfayı ne sıklıkta kontrol edeceğinizi zaten biliyor olabilirsiniz. Ardından her kontrolün kaç istek kullandığını öğrenin. Böylece bir ay için gereken paketi ve daha fazla sayfa eklerseniz kullanımın ne kadar artacağını tahmin edebilirsiniz.

Yanıt boyutu fiyatı mutlaka etkilemez. Tarife her istek için aynı tutarı alıyorsa tek yanıtta daha fazla veri almak, küçük bir yanıt almakla aynı maliyette olabilir. Yine de tarifenin neleri içerdiğini kontrol edin: bant genişliği, yanıt boyutu veya yürütme süresi sınırları olabilir. Ek veri işlemenin de ayrı ücreti olabilir.

İstek paketi kaç IP adresi alacağınızı belirlemez. Örneğin dönen bir hizmet, ortak bağlantı uç noktası üzerinden IP havuzuna erişim sağlayabilir. IP değişimleri ve bir adresin oturum boyunca korunması, hizmet ayarlarına bağlıdır. Tek başına IP değişimi, kaç isteğin ücretlendirileceğini söylemez.

Hizmet neyi tek istek sayar?

Önce isteği bağlantıdan ayırın. HTTP isteği, web sitesinden sayfa döndürmek veya veri sağlamak gibi bir şey yapmasını ister. Web sitesi bir yanıt gönderir. Verilerin iki yönde hareket etmesi, tek başına iki isteğin düşülmesi gerektiği anlamına gelmez. Bunun için ayrı bir faturalandırma kuralı gerekir.

Bağlantı, uygulamanın sunucuyla iletişim kurduğu kanaldır. Birden fazla istek aynı bağlantıyı kullanabilir. HTTP/1.1 bağlantının yeniden kullanılmasına, HTTP/2 ise aynı anda birden fazla alışverişin bağlantı üzerinden yürütülmesine izin verir. Bu nedenle istek sayısı, açılan bağlantılar ve aynı anda etkin olan bağlantılar farklı ölçümlerdir.

HTTPS başka bir ayrıntı ekler. HTTP proxy üzerinden bağlanırken uygulama, web sitesine tünel oluşturmak için genellikle CONNECT komutu gönderir. Sonraki istekler bu tünelin içinde şifreli olarak taşınır. Proxy sunucusu verileri iletir, ancak olağan kullanımda tek tek HTTP isteklerini okuyamaz. SOCKS proxy de hedefe bağlantı sağlar; her uygulama işlemi için mutlaka yeni bağlantı gerekmez.

Bu nedenle bazı hizmetler “istek” sözcüğünü, proxy sunucularının sayabildiği bir bağlantı veya başka bir olay anlamında kullanır. Diğerleri tek tek HTTP isteklerini veya API çağrılarını sayar. Dolayısıyla tarayıcının geliştirici araçlarındaki istek sayısı, sağlayıcının panelindeki kullanımdan farklı olabilir. Yalnızca HTTP, HTTPS veya SOCKS5 desteği, sayım kuralını belirlemez.

Büyük paket satın almadan önce küçük bir test yapın. Uygulamanın kaç görevi tamamladığını ve hizmetin kaç istek düştüğünü kaydedin. Daha sonra kullanmayı düşündüğünüz uygulamayı, protokolü ve ayarları kullanın. Basit bir HTTP istemcisiyle yapılan test, betikleri ve diğer sayfa kaynaklarını da yükleyen tarayıcının kullanımını göstermez.

Bir sayfa neden birden fazla istek kullanabilir?

Sayfayı açmak çoğu zaman ana belgesinden fazlasını gerektirir. Tarayıcı stilleri, betikleri, görselleri ve verileri ayrı ayrı yükler. Açık sayfa, güncellemeler için sunucuyla iletişim kurmayı sürdürebilir. Uygulama ayarlarına bağlı olarak bu isteklerin bir bölümü de proxy üzerinden geçer. Nasıl ücretlendirildikleri tarifeye bağlıdır.

Yönlendirmeyi izlemek ek bir istek oluşturur. Web sitesi sayfanın başka bir adreste olduğunu bildirirse yönlendirmeyi izlemek üzere yapılandırılmış uygulama, o adrese başka bir HTTP isteği gönderir. Bu nedenle basit bir istemciyle tek belgeyi almak ve sayfanın tamamını tarayıcıda açmak farklı sayıda istek kullanabilir. Listenizdeki URL sayısı, bunları işlemenin kaç istek gerektireceğini henüz söylemez.

API ters yönde çalışabilir: tek istek birçok kayıt alabilir. Bu örnekte tarayıcı, fiyatıyla birlikte kulaklık ürün sayfasını yüklemek için beş istek yapar. Uygulama aynı proxy sunucusunu kullanarak perakendecinin katalog API’sini çağırır ve tek istekte beş ürün fiyatı alır. Bu, ürün verisi sağlayan perakendecinin kendi API’sidir. Kataloğu sayfalar halinde döndürüyorsa her sayfa yeni bir istek gerektirir. API bu ayarı destekliyor ve gereken tüm verileri döndürüyorsa bazen yanıt başına ürün sayısını artırabilirsiniz.

Bu yaklaşım paketten daha fazla yararlı iş elde etmenize yardımcı olur. Tam sayfaları tekrar tekrar yüklemek, zaten kaydettiğiniz verileri almak ve fiyatları gerekenden sık kontrol etmek kotayı hızla tüketebilir. Çağrı başına birden fazla ürün almak, sonuçları kaydetmek ve uygun kontrol sıklığını seçmek aynı iş için gereken istekleri azaltır. Aynı iş yükünde kota, paketin geçerlilik süresi içinde daha uzun dayanabilir; alternatif olarak daha fazla ürünü kontrol etmek için kullanabilirsiniz.

Tamamlanan görev başına kullanımı ölçmek yararlıdır. Bu; tek sayfayı kontrol etmek, tam listeyi almak veya betikler çalıştıktan sonra görünen öğeyi kontrol etmek anlamına gelebilir. Bu sonuca ulaşmak için gereken dizinin tamamını ölçün. Yalnızca başlangıç URL’lerini sayarken kolayca gözden kaçabilen ek sayfa yüklemeleri de buna dahildir.

Bu ücretlendirme modeli nerede yararlıdır?

Zamanlanmış izleme

İstek kullanımı düzenli kontrollere bağlanabilir. Uygulama, sayfa kullanılabilirliğini, herkese açık listelerdeki değişiklikleri veya gereken bölgenin arama sonuçlarını izleyebilir. Hedef sayısını ve kontrol sıklığını önceden bilirsiniz. Test, her kontrolün kaç istek kullandığını gösterir ve aylık tüketimi tahmin etmeye yardımcı olur.

Farklı sayfaları aynı sıklıkta kontrol etmek zorunda değilsiniz. Bilgi günde bir kez değişiyorsa her dakika kontrol etmek genellikle aynı veriyi döndürür. Daha sık kontroller, değişikliği hızla saptamanın önemli olduğu sayfalara ayrılabilir. Bu, paketi ihtiyaç duyduğunuz gözlemler için kullanılabilir tutar.

API’ler ve dizinler üzerinden veri toplama

Buradaki kullanım, web sitesinin bilgiyi nasıl sağladığına bağlıdır. Liste gereken her şeyi zaten içeriyorsa her ayrıntı sayfasını açmak için neden yoktur. Ek istekler, eksik verili öğelere veya önceki çalıştırmadan bu yana değişmiş kayıtlara ayrılabilir. Tek çağrıda gereken verinin ne kadar fazlasını alırsanız koleksiyonun tamamı o kadar az istek gerektirir.

Hizmetin ne yaptığını da hesaba katmanız gerekir. Arama API’si ayrıştırılmış sonuçlar döndürebilirken olağan proxy sunucusu, indirmeyi ve işlemeyi uygulamanıza bırakır. Bunlar farklı miktarlarda iştir. Fiyatları karşılaştırırken yanıtın neler içerdiğini ve hâlâ kendiniz neler yapmanız gerektiğini kontrol edin.

Site denetimleri ve tarayıcı kontrolleri

Teknik denetimin çoğu zaman açık bir sırası vardır: adresi aç, yanıtı kontrol et, gerekirse yönlendirmeyi izle ve bulguyu kaydet. Çoğu adres benzer biçimde ele alınıyorsa test, kullanımı tahmin etmeyi kolaylaştırır. Tarayıcı kontrolü, betiklere, görsellere ve çalışan sayfa öğelerine bağlı olduğu için daha fazla istek gerektirebilir.

Kontrol yöntemini amacına göre seçin. Sayfanın yanıt verip vermediğini görmek için basit istemci çoğu zaman yeterlidir. Ödeme formunu test etmek, formun çalışması için gerekenleri yüklemeyi gerektirir. Gerekli dosyaları devre dışı bırakmak istekleri azaltır, ancak test artık kullanıcının deneyimini göstermez.

Hatalar ve yeniden denemeler kullanımı nasıl etkiler?

Gönderilen istek her zaman gereken veriyi döndürmez. Web sitesi hata, erişim doğrulaması veya farklı bir sayfa döndürebilir. HTTP 200 bile uygulamanın istediğini aldığını garanti etmez: durum kodu HTTP düzeyinde başarı bildirirken yanıt içeriğinin ayrıca kontrol edilmesi gerekir.

Bu isteklerin faturalandırma kuralları değişir. Bazı hizmetler gönderilen istekleri sayar. Diğerleri yalnızca kendi başarılı tamamlanma tanımına uyan yanıtları ücretlendirir. Yönetilen API, verileri almak için birkaç dahili denemeyi tek yanıtın fiyatına dahil edebilir. Ek modlar veya özellikler bazen faturalandırma kurallarını değiştirir. Bu nedenle “istek başına öde”, otomatik olarak “yalnızca alınan veri için öde” anlamına gelmez.

Uygulamanızın yeniden denemesi, hizmet içindeki yeniden denemeden farklıdır. Uygulama isteği tekrar gönderdiğinde yeni bir istek oluşturur. Hizmet zaten gönderdiğiniz işi yeniden denediğinde bu denemeler fiyatına dahil olabilir. Paketinizden hangi denemelerin düşüldüğünü öğrenin.

Testte üç sayı kaydedin: başlatılan görevler, ücretlendirilen istekler ve tamamlanan görevler. Tamamlanma amaca bağlıdır. Veri toplamada yanıt, gereken alanları ve yeterince güncel bilgileri içermelidir. Kullanılabilirlik izlemede, kullanılamayan web sitesini doğru saptamak da tamamlanmış bir kontroldür.

Bu sayılar işin gerçek maliyetini göstermeye yardımcı olur. Yanıtlar sürekli yeni deneme gerektiriyor veya atılmak zorunda kalıyorsa ucuz isteklerin karşılığı düşük olabilir. Daha pahalı hizmet, işin bir bölümünü sizin için yapabilir. Uygulamanıza kalan iş dahil, gereken sonucu elde etmek için yapılan harcamayı karşılaştırın.

Gereken paket nasıl hesaplanır?

Önce planlanan işi sayın: kaç hedefin ne sıklıkta işleneceğini. Ardından testte gözlenen yeniden denemeler gibi normal almanın ötesinde gereken istekleri ekleyin. Farklı davranıyorlarsa farklı sayfa gruplarını ayrı hesaplayın. İş yükü artışı için ayrılan yedek payı da ayrı tutun; böylece aynı ek istekler iki kez eklenmez.

Açıklayıcı bir örnek alalım. Uygulama 150 URL’yi her 30 dakikada bir, 30 gün boyunca kontrol eder. Seçilen tarifede normal kontrolün tek istek kullandığını ve ek denemelerin kullanımı %5 artırdığını varsayalım. Bu örnekteki tüm rakamlar ve fiyatlar varsayımsaldır; sağlayıcı test sonuçları veya ProxyCompass tarifesi değildir.

Seçilen paket 23,200 istek yedek bırakır. Paket geçerli kaldığı sürece iş yükü artışını karşılayabilir. Beklenen yeniden denemeler 10,800 ek denemeye zaten dahildir; bu yedek pay, aynı yeniden denemelerin kullanımı olarak tekrar sayılmamalıdır.

Paketin $10 olduğunu varsayalım. Paket 250 bin istek içerir; dolayısıyla bin istek başına nominal fiyat $0.04 olur. Paketin tamamı için $10 ödersiniz. Beklenen 226,800 istek kullanımını bu birim fiyatla çarpmak $9.072 verir. Bu, satın alma tutarı değil kullanılan bölümün değeridir: sabit paket yine $10 tutmuştur.

Şimdi ek denemelerden sonra uygulamanın zamanlanmış 216,000 kontrolün tamamını bitirdiğini varsayalım. Tamamlanan bin kontrolün maliyeti yaklaşık $0.0463 olur: $10 ÷ 216,000 × 1,000. Bu tutar hem ek istekleri hem de satın aldığınız yedek payı hesaba katar. Daha az kontrol tamamlanıyorsa harcamayı bunların gerçek sayısına bölün.

Diğer görevlerde hesaplama aynı biçimde çalışır. Kullanıma göre faturalandırmada, birim fiyatın kaç isteği kapsadığını hesaba katarak ücretlendirilen istekleri tarife birim fiyatıyla çarpın. Pakette satın alma fiyatının tamamını kullanın. Ardından harcamayı tamamlanan görev sayısına bölün. Birkaç proje aynı paketi paylaşıyorsa maliyeti aralarında nasıl dağıtacağınıza karar verin.

Uygulamanın işi zamanında bitirip bitiremeyeceğini de kontrol edin. Örneğimiz günde 7,200 kontrol gerektirir; bu, dakikada ortalama beş başlatma demektir. Her yarım saatte 150 kontrolün tamamını birlikte başlatabilir veya aralığa yayabilirsiniz. Her kontrol örnekte kabul edilen sayıda deneme gerektirirse paket kullanımı aynı olur, ancak başlangıç anındaki yük farklılaşır. Bağlantı sınırı veya istek hızı sınırı ilk takvimin planlandığı gibi çalışmasını önleyebilir.

Gereksiz istekler nasıl azaltılır?

Yinelenen adresleri kaldırın ve iş ilerledikçe sonuçları kaydedin. Bir hatadan sonra uygulama durduğu yerden devam etmelidir. Her seferinde bütün listeyi yeniden başlatırsa önceden işlenmiş sayfalar paketi tekrar tüketir. Hangi görevlerin tamamlandığını ve hangilerinin hâlâ işlenmesi gerektiğini kaydedin.

Veriyi almak için gereken yükleme yöntemini kullanın. Gereken metin sunucu yanıtında zaten varsa tarayıcı çalıştırmak gereksiz olabilir. Veri yalnızca betikler yürütüldükten sonra görünüyorsa basit indirme yetmeyebilir. Veri toplama hizmetlerinde tarayıcı modu ve ek özellikler bazen daha fazla kredi kullanır veya başka birim fiyatla ücretlendirilir. Dolayısıyla bir kredi her zaman bir isteğe eşit değildir.

Yanıt boyutunu küçültmek her zaman istek tasarrufu sağlamaz. Sağlayıcı HTTP çağrılarını sayıyorsa kısa yanıt uzun yanıtla aynı sayıda istek kullanabilir. Sayıyı azaltmak için değişmeyen verileri daha seyrek kontrol edebilir, kaydedilmiş sonucu yeniden kullanabilir veya tek API çağrısında birkaç kayıt alabilirsiniz. Bilgi, göreviniz için yine yeterince güncel olmalıdır.

Yeniden denemeleri sınırlayın ve isteğin neden başarısız olduğunu değerlendirin. Web sitesi geçici olarak kullanılamıyorsa veya yavaşlamanızı istiyorsa hemen yeniden denemek aynı yanıtı döndürebilir ve bir istek daha harcayabilir. Duraklamak veya sıklığı azaltmak daha yararlı olabilir. Veri oluşturan veya değiştiren işlemlerde özellikle dikkatli olun: yeniden göndermeden önce ilk denemenin sonucunu kontrol edin. Yanıtın kaybolması sunucunun hiçbir şey yapmadığı anlamına gelmez.

Değişikliklerden sonra kullanımla birlikte sonuçları da kontrol edin. Uygulama işin bir bölümünü yapmayı bıraktığı için istek sayısı düşmüş olabilir. Daha az istekle gereken veriyi aynı eksiksizlik ve güncellikle almaya devam ediyorsanız azalma yararlıdır.

Tarife seçerken neler kontrol edilmeli?

Önce hizmetin web siteleriniz ve uygulamanız için çalıştığından emin olun. Proxy türü, kullanılabilir ülkeler, oturum davranışı ve sağlanan IP adresleri üzerinden gereken sayfalara erişim önemlidir. Ardından dahil olan işi karşılaştırın: sayfayı kim yüklüyor, tarayıcıyı kim çalıştırıyor, verileri kim çıkarıyor ve başarısız denemeleri kim tekrarlıyor? Bu, iki hizmetin istek başına neden farklı fiyatlar aldığını açıklamaya yardımcı olur.

Paketin geçerlilik süresini, ek kota kurallarını ve kullanılmayan isteklere ne olduğunu kontrol edin. Daha düşük istek fiyatlı büyük paket, ihtiyaç duyulan işlerde zamanında kullanılabiliyorsa iyi karşılık verir. Satın alınan bazı istekler kullanılmazsa tamamlanan görev başına maliyet, daha küçük paketinkinden yüksek olabilir.

Karşılaştırma için projenizden tipik sayfalar seçin; genellikle zorluk çıkaranlar da dahil olsun. Harcanan zamanı, kullanılan istekleri, elde edilen sonuçları ve uygulama ayarlarını kaydedin. Bu test, gereken paket boyutunu, işin yaklaşık maliyetini ve zamanında bitirip bitiremeyeceğinizi gösterecektir.