Yüksek Hacimli Scraping için Datacenter Proxy

Bu sayfa “hangi proxy türünü seçmeliyim” sorusunu yanıtlamaz. Ekibiniz datacenter çıkışıyla ilerlemeye zaten yakınsa ve asıl soru “günde yüz binlerce sayfayı hedefi yormadan, bütçeyi aşmadan ve sürpriz engellere takılmadan nasıl toplarız” ise doğru yerdesiniz. Odak dört mühendislik değişkeni: gecikme, verim, eşzamanlılık ve maliyet. Beşinci değişken de hedefin kendisidir; bazı siteler datacenter ağlarından gelen trafiğe ev bağlantılarından gelen trafikten farklı davranır ve bu farkı ölçmeden ölçek planı yapmak boşa emek olur.

Yüksek hacim burada belirsiz bir sıfat değil, ölçülebilir bir durumdur. İş yükünüzü sayfa sayısı, sayfa başına aktarılan bayt, zaman penceresi ve hedef başına kabul edilebilir istek hızı ile tarif edebiliyorsanız proxy ihtiyacınızı da hesapla çıkarabilirsiniz. Tahminle paket almak ya gereksiz harcamaya ya da işin ortasında kotanın bitmesine yol açar. Aşağıdaki bölümler bu dört girdiyi sırayla rakama çevirir, ardından katalogdaki paketlerle eşleştirir.

DatacenterProxy yalnız datacenter ürün aileleri sunar: rotating IPv4, rotating IPv6, static IPv4 ve static IPv6. Hepsi HTTP, HTTPS ve SOCKS5 protokolleriyle kullanılır. Bu sayfadaki fiyatlar doğrulanmış katalogdan gelir; sayfa boyutu, yanıt süresi ve yeniden deneme oranı gibi girdiler ise sizin iş yükünüze ait olduğu için her seferinde “varsayım” olarak işaretlenmiştir. Kendi ölçümlerinizle değiştirmeniz beklenir.

Planlamanın ilk adımı iş yükünü dört sayıyla yazmaktır. Birincisi dönem başına sayfa sayısıdır; tekrarlanan taramalar dahil toplam istek adedi olarak düşünün. İkincisi sayfa başına aktarılan bayttır; tarayıcıda görünen sayfa boyutu değil, istemcinizin proxy üzerinden gerçekten indirdiği veri miktarıdır. Görselleri, yazı tiplerini ve üçüncü taraf betikleri indirmeyen bir HTML toplayıcısı ile tam tarayıcı açan bir otomasyon arasında bu değer kat kat farklıdır. Üçüncüsü zaman penceresidir: verinin ne kadar sürede toplanması gerektiği. Dördüncüsü hedef başına izin verilen istek hızıdır; bu sayı sizin değil, hedefin kapasitesine ve kurallarına göre belirlenir.

Bu dört sayıdan iki kritik çıktı türetilir. Toplam trafik, sayfa sayısı ile sayfa başına baytın çarpımıdır ve GB bazlı faturalanan ürünlerde maliyeti doğrudan belirler. Gerekli eşzamanlılık ise saniyedeki istek hızı ile ortalama yanıt süresinin çarpımıdır. Bu ikinci ilişki kuyruk teorisinde Little yasası olarak bilinir ve sezgiyi düzeltir: daha fazla paralel bağlantı açmak tek başına hızlandırmaz, yalnız yanıt süresinin yarattığı bekleme boşluğunu doldurur. Hedefin izin verdiği hız sabitse ve yanıt süresi uzarsa aynı hızı korumak için daha fazla eşzamanlı bağlantı gerekir; yanıt süresi kısalırsa daha azıyla yetinirsiniz.

Sayfa başına bayt değerini tahmin etmeyin; küçük bir pilotla ölçün. Aynı sitenin kategori sayfası, ürün sayfası ve arama sonucu sayfası çok farklı boyutlarda olabilir. Sıkıştırma da hesabı değiştirir: istemciniz Accept-Encoding başlığıyla gzip veya br kabul ediyorsa aktarılan bayt, açılmış HTML boyutundan belirgin biçimde küçüktür. Ölçümü sıkıştırılmış aktarım üzerinden yapın; çünkü proxy trafiği aktarılan veri üzerinden sayılır, belleğe açılan metin üzerinden değil.

Proxy kullanan bir isteğin süresi tek bir sayı gibi görünür ama aslında art arda eklenen parçalardan oluşur. İstemciden proxy sunucusuna bağlantı kurulur, proxy hedefin alan adını çözer, hedefle TCP ve TLS el sıkışması yapılır, hedef sunucu yanıtı üretir ve gövde iki ağ parçası boyunca geri taşınır. Datacenter proxy’nin bu zincirdeki avantajı, çıkış noktasının iyi bağlantılı bir veri merkezinde durmasıdır; ev bağlantısının değişken yükleme hızı ve son kilometre dalgalanması devreye girmez. Yine de hangi parçanın baskın olduğunu bilmeden yapılan optimizasyon çoğu zaman yanlış yere gider.

Tabloda dikkat çeken nokta, en büyük kazancın çoğu zaman proxy değişikliğinden değil bağlantı yönetiminden gelmesidir. Her istekte yeni bir TLS oturumu açan bir istemci, aynı proxy ve aynı hedefle bile gereksiz turlar harcar. Rotating ürünlerde IP’nin hangi anda değiştiği bağlantı yeniden kullanımını etkileyebilir; bu nedenle dönüş davranışını entegrasyon dokümantasyonuna göre yapılandırın ve bağlantı havuzunu bununla uyumlu tutun. Ürün sayfalarında “her istekte anlık değişim” gibi kanıtsız bir iddia yapılmaz; davranışı kendi pilotunuzda gözlemleyin.

Lokasyon seçimi de gecikme bütçesinin parçasıdır ama içerik ihtiyacıyla dengelenmelidir. Hedef site ülkeye göre farklı fiyat veya stok gösteriyorsa çıkış ülkesi veriyi belirler ve gecikme ikinci planda kalır. İçerik ülkeden bağımsızsa hedefin sunucusuna veya CDN düğümüne yakın bir çıkış seçmek her istekte tasarruf sağlar. Katalogda rotating IPv4 için Amerika Birleşik Devletleri, Birleşik Krallık, Almanya, Fransa, Türkiye, Hollanda ve Kanada başta olmak üzere on beş ana lokasyon listelenir; static IPv4 beş ülkede, static IPv6 on dokuz ülkede, rotating IPv6 dokuz ülkede sunulur.

Yüksek hacimli bir toplayıcıda iki ayrı sınır vardır ve ikisi de gereklidir. Küresel sınır, sizin altyapınızın ve proxy planınızın kaldırabileceği toplam eşzamanlı bağlantıdır; port bazlı bir üründe port sayısı, kendi sunucunuzda ise açık dosya ve bellek bu sınırı belirler. Hedef başına sınır ise her alan adı için ayrı tutulur ve hedefin kapasitesini korur. Yalnız küresel sınır koyan bir sistem, kuyrukta tek bir hedefin URL’leri birikince bütün kapasiteyi o hedefe yöneltir; bu hem hedefi yorar hem de 429 yanıtlarının ardından gelen engellerle sonuçlanır.

Geri çekilme (backoff) üçüncü bileşendir. Hedef 429 veya 503 döndürdüğünde aynı hızla devam etmek, sorunu büyütür. Doğru davranış, Retry-After başlığı varsa ona uymak, yoksa bekleme süresini her denemede katlayarak artırmak ve küçük bir rastgele pay eklemektir. Rastgele pay, aynı anda başarısız olan çok sayıda isteğin aynı anda yeniden denenmesini önler. Bir hedeften üst üste hata geliyorsa o hedefin kuyruğunu bir süre tamamen durdurmak, diğer hedeflerin işini etkilemeden sorunu izole eder.

Aşağıdaki iskelet bu üç kuralı bir araya getirir: robots.txt kontrolü, küresel ve hedef başına semaforlar, Retry-After’a saygı gösteren üstel geri çekilme. Üretimde kalıcı kuyruk, kayıt ve metrik toplama eklemeniz gerekir; amaç mimarinin omurgasını göstermektir.

import asyncio
import random
import urllib.robotparser
from urllib.parse import urlsplit

import aiohttp

PROXY = "http://KULLANICI:ŞİFRE@PROXY_HOST:PORT"
USER_AGENT = "OrnekToplayici/1.0 (iletisim: [email protected])"
GLOBAL_LIMIT = 28          # varsayım: hesaplanan toplam eşzamanlılık
PER_HOST_LIMIT = 3         # varsayım: hedef başına üst sınır
MAX_RETRIES = 4

global_sem = asyncio.Semaphore(GLOBAL_LIMIT)
host_sems = {}
robots_cache = {}


def host_sem(host):
    if host not in host_sems:
        host_sems[host] = asyncio.Semaphore(PER_HOST_LIMIT)
    return host_sems[host]


async def allowed(session, url):
    parts = urlsplit(url)
    base = f"{parts.scheme}://{parts.netloc}"
    if base not in robots_cache:
        rp = urllib.robotparser.RobotFileParser()
        try:
            async with session.get(base + "/robots.txt", proxy=PROXY) as r:
                text = await r.text() if r.status == 200 else ""
        except aiohttp.ClientError:
            text = ""
        rp.parse(text.splitlines())
        robots_cache[base] = rp
    return robots_cache[base].can_fetch(USER_AGENT, url)


async def fetch(session, url):
    if not await allowed(session, url):
        return url, "robots_disallow", None
    host = urlsplit(url).netloc
    for attempt in range(MAX_RETRIES):
        async with global_sem, host_sem(host):
            try:
                async with session.get(url, proxy=PROXY) as r:
                    if r.status in (429, 503):
                        wait = r.headers.get("Retry-After")
                        delay = int(wait) if wait and wait.isdigit() else 2 ** attempt
                    elif r.status == 403:
                        return url, 403, None   # tekrar deneme yok, incele
                    else:
                        return url, r.status, await r.read()
            except (aiohttp.ClientError, asyncio.TimeoutError):
                delay = 2 ** attempt
        await asyncio.sleep(delay + random.uniform(0, 1))
    return url, "max_retries", None


async def main(urls):
    timeout = aiohttp.ClientTimeout(total=30, connect=10)
    headers = {"User-Agent": USER_AGENT, "Accept-Encoding": "gzip, br"}
    connector = aiohttp.TCPConnector(limit=GLOBAL_LIMIT, ttl_dns_cache=300)
    async with aiohttp.ClientSession(
        timeout=timeout, headers=headers, connector=connector
    ) as session:
        return await asyncio.gather(*(fetch(session, u) for u in urls))


if __name__ == "__main__":
    sonuc = asyncio.run(main(["HEDEF_URL"]))

İskelette 403 yanıtı bilinçli olarak yeniden denenmez. 403 genellikle geçici bir yük sinyali değil, bir politika kararıdır; aynı isteği farklı bir IP ile tekrar göndermek sorunu çözmez, yalnız hedefin gözünde davranışınızı daha şüpheli hâle getirir. 403’ler ayrı bir listeye düşmeli ve bir insan tarafından incelenmelidir. Bekleme sırasında semaforların serbest bırakıldığına da dikkat edin: uyuyan bir istek, kapasiteyi başka hedeflerin işine bırakır.

Her IP adresi bir otonom sisteme (ASN) aittir ve bu bilgi herkese açık kayıtlardan okunabilir. Datacenter IP’leri barındırma ve bulut şirketlerinin ASN’lerinde yer alır. Bazı hedefler bu bilgiyi hiç kullanmaz; bazıları yalnız şüpheli davranışla birleştiğinde dikkate alır; bazıları ise belirli sayfalarda veri merkezi ağlarından gelen trafiğe baştan farklı bir politika uygular. Hangi grupta olduğunuzu bilmek için tahmin değil, pilot gerekir.

ASN tabanlı politikanın sinyalleri her zaman açık bir hata kodu olmaz. Daha zor fark edilen biçim “yumuşak engel”dir: hedef 200 döndürür ama içerik eksiktir, fiyat alanı boştur, liste sayfası sıfır ürün gösterir ya da sayfa bir doğrulama ekranına dönüşür. Durum kodu sağlıklı göründüğü için bu tür yanıtlar fark edilmeden veri tabanına yazılır ve haftalar sonra raporlarda anlamsız boşluklar olarak ortaya çıkar. Bu yüzden yüksek hacimli bir toplayıcıda durum kodu kontrolü yetmez; içerik doğrulaması da gerekir.

Pilot testi için küçük ve ucuz bir başlangıç yeterlidir. Katalogda rotating IPv4 için 2 GB’lık paket 1 dolar olarak listelenir; bu miktar, HTML odaklı bir toplayıcıda her hedeften birkaç yüz sayfalık örnek almak için çoğu zaman yeter. Pilotta her hedef için başarı oranını değil, örüntüyü kaydedin: hangi sayfa türünde, kaçıncı istekte, hangi hızda ne değişti. Aynı örneklemi düşük hızda tekrarlayıp sonuçları karşılaştırmak, sorunun hız mı yoksa ağ türü mü olduğunu ayırmanın en ucuz yoludur.

Datacenter kararı verildikten sonra asıl seçim faturalama modeliyle ilgilidir. Dört ürün ailesinin her biri farklı bir maliyet eğrisi çizer ve iş yükünüzün hangi boyutu büyüdükçe hangi modelin avantajlı hâle geldiğini belirler. GB bazlı model trafik büyüdükçe doğrusal artar; port bazlı model eşzamanlılık büyüdükçe artar; IP başına model ise havuzun genişliği büyüdükçe artar.

Rotating IPv4’te 10 GB ve üzerindeki paketlerin hepsi GB başına 0,60 dolara denk gelir; 2 GB’lık paket ise GB başına 0,50 dolar eder ama küçük olduğu için pilot amaçlıdır. Yani hacim büyüdükçe birim fiyat düşmez, toplam ihtiyacı paketlerle tam karşılamak önemlidir. Static IPv4’te IP başına dönemlik fiyat 100 IP’de 0,15, 250 IP’de 0,10, 500 IP’de 0,09, 1000 IP’de 0,08 dolardır. Rotating IPv6’da 5 port paketinde port başına 16 dolar, 10 port paketinde ise port başına 17,50 dolar düşer; bu nedenle 10 port yerine iki adet 5 port paketinin katalogda mümkün olup olmadığını sipariş adımında kontrol etmek mantıklıdır.

Somut bir örnekle ilerleyelim. Bir fiyat karşılaştırma ekibi, herkese açık ürün sayfalarını on iki e-ticaret sitesinden her gün yeniden topluyor. Fiyatların sabah raporuna yetişmesi gerektiği için tarama gece altı saatlik bir pencereye sığmak zorunda. Sayfalar HTML olarak indiriliyor, görsel ve betik çekilmiyor, istemci sıkıştırma kabul ediyor. Aşağıdaki girdilerin tamamı varsayımdır; kendi pilotunuzun ölçümleriyle değiştirin.

Trafik tamamen rotating IPv4 üzerinden geçerse 1.166,4 GB, GB başına 0,60 dolarla 699,84 dolar eder. Paketlerle tam karşılamak için on bir adet 100 GB, bir adet 50 GB ve bir adet 20 GB paket alındığında 1.170 GB için 660 + 30 + 12 = 702 dolar ödenir. Bin sayfa başına maliyet yaklaşık 0,078 dolardır (702 / 9.000). Sayfa başına veri 120 KB yerine 60 KB’a indirilebilirse trafik ve maliyet yaklaşık yarıya iner; bu yüzden bir sonraki bölümdeki trafik azaltma teknikleri, proxy pazarlığından daha büyük tasarruf sağlar.

Şimdi hedeflerin beşinin IPv6 üzerinden erişilebilir olduğunu ve trafiğin eşit dağıldığını varsayalım. Trafiğin 5/12’si, yani yaklaşık 486 GB IPv6’ya taşınır; IPv4’te kalan 680,4 GB için altı adet 100 GB, bir adet 50 GB ve iki adet 20 GB paket 690 GB sağlar ve 360 + 30 + 24 = 414 dolar tutar. IPv6 kısmı 5 portluk rotating IPv6 paketiyle karşılanabiliyorsa aylık 80 dolar eklenir ve toplam 494 dolara iner. Bu hesabın geçerli olması için iki şartı doğrulayın: beş hedefin IPv6 üzerinden aynı içeriği gerçekten sunması ve port başına eşzamanlı bağlantı koşulunun bu beş hedefin yaklaşık on beş bağlantılık ihtiyacını karşılaması.

GB bazlı faturalamada proxy maliyeti, istemcinizin ne kadar veri indirdiğinin doğrudan yansımasıdır. Bu yüzden en etkili maliyet kalemi çoğu zaman paket seçimi değil, toplayıcının disiplinidir. Aşağıdaki teknikler hem trafiği hem de hedefin yükünü azaltır; yani hem bütçeye hem de hedefle ilişkinize iyi gelir.

• Koşullu istek kullanın: hedef ETag veya Last-Modified başlığı veriyorsa sonraki taramada If-None-Match ya da If-Modified-Since gönderin. Değişmeyen sayfa 304 ile ve gövdesiz döner.
• Site haritasındaki lastmod alanını okuyun: yalnız değişen URL’leri kuyruğa alın, her gün bütün kataloğu baştan indirmeyin.
• Sıkıştırmayı açın: Accept-Encoding başlığıyla gzip veya br kabul edin; ölçümünüzü sıkıştırılmış aktarım üzerinden yapın.
• Gerekmeyen kaynakları indirmeyin: veri HTML içinde geliyorsa görsel, yazı tipi, stil ve üçüncü taraf betik isteklerini engelleyin. Tam tarayıcı yalnız içerik başka türlü oluşmuyorsa kullanılmalıdır.
• URL’leri normalleştirin: sıralama, izleme ve oturum parametreleri yüzünden aynı sayfanın onlarca kopyasını indirmeyin; kanonik adresi tercih edin.
• Yumuşak engeli erken yakalayın: beklenen alan yoksa aynı hedefe aynı hızla devam etmeyin; kuyruğu durdurun ve trafiği boşa harcamayın.
• Yeniden denemeyi sınırlayın: üst sınırsız yeniden deneme, kalıcı bir hatayı katlanarak büyüyen bir trafik kalemine çevirir.
• Bağlantıyı yeniden kullanın: keep-alive ve bağlantı havuzu, her istekte el sıkışma baytlarını ve süresini tekrar ödemenizi önler.

Bu tekniklerin etkisini tahmin etmek yerine pilotta ölçün. Aynı URL kümesini bir kez koşullu istek olmadan, bir kez koşullu istekle toplayıp aktarılan toplam baytı karşılaştırmak, hangi hedeflerde ciddi tasarruf olduğunu gösterir. Dinamik fiyatların her istekte yeniden üretildiği sitelerde 304 oranı düşük kalabilir; statik ağırlıklı kataloglarda ise aynı tarama çok daha az veriyle tamamlanabilir.

Hacim büyüdükçe küçük oranlı hatalar mutlak sayıda büyür ve fark edilmeden trafik yer. Her hata türü için ayrı sayaç tutun ve hata oranı belirli bir eşiği geçtiğinde ilgili hedefin kuyruğunu otomatik durdurun. Aşağıdaki tabloda çözümlerin hiçbiri bir korumayı atlatmaya dayanmaz; amaç sorunun kaynağını bulup ölçülü davranmaktır.

Hata sınıflaması aynı zamanda maliyet kontrolüdür. Yeniden denenebilir hatalar (429, 502, 503, zaman aşımı) ile yeniden denenmemesi gereken hatalar (403, 407, doğrulama sayfası) arasında kodda net bir ayrım yapın. Bu ayrım yapılmazsa kalıcı hatalar yeniden deneme döngüsünde GB tüketmeye devam eder.

Datacenter proxy yüksek hacimli işlerde güçlüdür ama her hedef için doğru araç değildir. Bu sınırları baştan yazmak, haftalarca süren verimsiz uğraşı önler. İlk sınır ağ türüne dayalı politikadır: hedef belirli sayfaları yalnız ev veya mobil bağlantılardan gelen trafiğe açıyorsa datacenter çıkışıyla sağlıklı sonuç alamazsınız. Bu durumda IP değiştirmek ya da istek başlıklarını oynamak sorunu çözmez. Bu sitede yalnız datacenter ürünleri sunulur; ev kullanıcısı kimliği gerçekten gerekiyorsa farklı ürün aileleri değerlendirilmelidir.

İkinci sınır lokasyon ayrıntısıdır. Katalogdaki lokasyonlar ülke düzeyindedir. Hedef içerik şehir veya bölge düzeyinde değişiyorsa ülke seçimi yeterli olmayabilir; bu ihtiyacı pilotta doğrulayın. Üçüncü sınır, oturum ve hesap gerektiren alanlardır: kullanıcı hesabıyla açılan sayfaları yüksek hacimde toplamak çoğu zaman kullanım koşullarına aykırıdır ve kişisel veri riski taşır. Dördüncü sınır ise hukuki ve etik çerçevedir: hedef kullanım koşullarında otomatik toplamayı açıkça yasaklıyorsa doğru yol resmi API, veri lisansı ya da iş birliğidir.

Yüksek hacimli bir projeyi tek seferde açmak yerine ölçülebilir aşamalarla büyütmek, hem hedefi hem bütçeyi korur. Aşağıdaki sıra, küçük bir pilotla başlayıp hesaplanmış bir üretim planına varmak için kullanılabilir.

1. Hedef listesini çıkarın ve her alan adı için robots.txt kurallarını, Crawl-delay değerini ve kullanım koşullarının otomatik erişim maddelerini kaydedin. Yasaklayan hedefleri listeden çıkarın.
2. Her hedeften sayfa türüne göre küçük bir URL örneklemi seçin: liste, ürün ve varsa arama sayfası ayrı ayrı.
3. Küçük bir rotating IPv4 paketiyle düşük hızda pilot tarama yapın; her istek için durum kodunu, aktarılan baytı, bağlantı süresini ve ilk bayta kadar geçen süreyi kaydedin.
4. Yanıtlara içerik doğrulama kuralı uygulayın: beklenen alanlar dolu mu, liste sayfası ürün içeriyor mu.
5. Aynı örneklemi biraz daha yüksek hızda tekrarlayın ve 429 veya yumuşak engel eşiğinin nerede başladığını gözlemleyin. Üretim hızını bu eşiğin belirgin biçimde altında belirleyin.
6. IPv6 adayı hedeflerde AAAA kaydını ve gerçek IPv6 erişimini kontrol edin; IPv6 üzerinden gelen içeriğin IPv4 ile aynı olduğunu doğrulayın.
7. Ölçülen sayfa başına bayt, yanıt süresi ve yeniden deneme oranıyla bu sayfadaki senaryo tablosunu kendi rakamlarınızla yeniden hesaplayın.
8. Hesaba göre paket karışımını seçin; üretimi önce kapasitenin bir kısmıyla açın, hata sayaçlarını ve günlük trafik tüketimini bir hafta izleyin, ardından tam hıza çıkın.

Pilot sonuçlarını yalnız ortalama olarak raporlamayın. Yanıt sürelerinin dağılımı, özellikle en yavaş yüzde birlik dilim, eşzamanlılık planını ortalamadan daha çok etkiler. Uzun kuyruk yanıtları bağlantıları meşgul eder ve küresel semaforu doldurur; zaman aşımı sınırını bu dağılıma göre seçmek, takılan isteklerin kapasiteyi kilitlemesini önler.

Aşağıdaki maddelerin her biri, yüksek hacimli datacenter scraping projelerinde sonradan pahalıya patlayan bir eksikliği önler. Listeyi proje başında bir kez değil, her yeni hedef eklendiğinde yeniden gözden geçirin.

• Her hedef için robots.txt ve kullanım koşulları okundu, otomatik erişime izin verilmeyen sayfalar kapsamdan çıkarıldı.
• Toplanan veride kişisel veri yok; varsa alan düzeyinde ayıklanıyor ve saklanmıyor.
• İstemci tanımlayıcı bir User-Agent ve iletişim bilgisi gönderiyor; kimlik gizlenmiyor.
• Küresel eşzamanlılık sınırı ve hedef başına eşzamanlılık sınırı ayrı ayrı tanımlı.
• 429 ve 503 için Retry-After’a uyan üstel geri çekilme var; yeniden deneme sayısının üst sınırı belli.
• 403, 407 ve doğrulama sayfası yeniden denenmiyor, ayrı listeye düşüyor.
• Durum koduna ek olarak içerik doğrulama kuralı çalışıyor; yumuşak engel fark ediliyor.
• Sayfa başına bayt, yanıt süresi ve yeniden deneme oranı pilotta ölçüldü; maliyet hesabı bu ölçümlerle yapıldı.
• Koşullu istek, sıkıştırma ve gereksiz kaynak engelleme etkin.
• IPv6 kullanılacak hedeflerde AAAA kaydı ve içerik eşliği doğrulandı.
• Günlük trafik tüketimi ve kalan GB izleniyor; kota bitmeden uyarı veriliyor.
• Proxy kimlik bilgileri kod deposunda değil, gizli değişken yönetiminde tutuluyor.

Son bir not: proxy, erişim katmanını sağlar; neyin, hangi hızla ve hangi amaçla toplandığına dair sorumluluk kullanıcıdadır. Hedef sitenin kurallarına uymayan bir toplama işi, hangi altyapıyla yapılırsa yapılsın sürdürülebilir değildir.