Tarayıcının yeterince eşzamanlı isteği yapılandırılmış. Yine de proxy havuzundan başka bir adres istediğinde duruyor. Daha fazla proxy eklemek o duraklamaya dokunmuyor.

Yaygın bir middleware deseni requests.get(pool_url) çağrısını process_request() içinde yapar. Bu, Scrapy'nin asenkron motoruyla işbirliği yapması beklenen bir yolda senkron bir ağ işlemidir. Çağrı beklerken aynı olay döngüsü iş parçacığındaki ilgisiz işleri tutabilir.

İşte iki istek var

Bir istek havuz hizmetinden bir uç nokta alır. Diğeri bu uç noktayı hedefle iletişim kurmak için kullanır. İkisini ayrı ayrı ölçün ve raporlayın. Yavaş bir havuz API'si, uygulama ona bağlanmadan önce bile her seçilen proxy'yi yavaş gösterebilir.

Kurulu Scrapy sürümünün desteklediği asenkron bir keşif entegrasyonu kullanın veya her isteğin kritik yolu dışında sınırlı bir yerel uç nokta kümesi edinip yenileyin. Engelleme yapan iş taşınacaksa, o yürütücüye kendi sınırlarını ve zaman aşımı işlemesini verin; sınırsız bir kuyruk yalnızca gecikmenin yerini değiştirir.

Her istek için otomatik olarak bir keşif çağrısı daha yapmayın. Kısa ömürlü bir önbellek veya kiralanmış bir toplu iş, hizmetin gerçek uç nokta politikasına ömrü uyduğu sürece havuz hizmetine bağımlılığı azaltabilir.

Başarısız bir aramanın ne anlama geldiğini tanımlayın

Boş veya başarısız bir havuz yanıtı proxy üst verilerini sessizce kaldırıp doğrudan isteğe izin vermemelidir. Açık bir sonuç seçin: görev bütçesi içinde beklemek, başarısız olmak veya onaylanmış önbelleklenmiş bir uç nokta kullanmak.

Havuz API'sinin kendi rotasını da açık tutun. İç hizmetse, özel ana makine adını seçilmesine yardım ettiği proxy üzerinden göndermek döngüsel bir bağımlılık yaratabilir.

Keşif, ilgisiz işi engellemeden çalışmaya başladığında olağan proxy işlemini inceleyin. Bunlar ayrı onarımlardır ve zamanlamaları günlükte ayrı alanları hak eder.

İlgili makaleler