Blokujące zapytanie do puli proxy może zatrzymać Scrapy

Pająk ma skonfigurowaną wystarczającą liczbę równoczesnych żądań. Mimo to zatrzymuje się za każdym razem, gdy prosi pulę proxy o inny adres. Dodanie kolejnych proxy nie zmienia tej pauzy.

Typowy wzorzec middleware wywołuje requests.get(pool_url) wewnątrz process_request(). To synchroniczna operacja sieciowa na ścieżce, która powinna współpracować z asynchronicznym silnikiem Scrapy. Gdy wywołanie czeka, może wstrzymywać niezwiązane prace w tym samym wątku pętli zdarzeń.

W zadaniu są dwa żądania

Jedno żądanie pobiera endpoint z usługi puli. Drugie używa tego endpointu do kontaktu z celem. Mierz je i raportuj osobno. Wolne API puli może sprawić, że każdy wybrany proxy będzie wyglądał na wolny, zanim aplikacja w ogóle się z nim połączy.

Użyj integracji asynchronicznego wykrywania obsługiwanej przez zainstalowaną wersję Scrapy albo pobierz i odświeżaj ograniczony lokalny zestaw endpointów poza krytyczną ścieżką każdego żądania. Jeśli blokującą pracę trzeba przenieść, daj temu wykonawcy własne limity i obsługę limitów czasu; nieograniczona kolejka jedynie przenosi opóźnienie.

Nie wysyłaj automatycznie kolejnego wywołania wykrywania przy każdym żądaniu. Krótkotrwały cache lub dzierżawiona partia mogą zmniejszyć zależność od usługi puli, o ile ich czas życia pasuje do rzeczywistej polityki endpointów usługi.

Zdefiniuj, co oznacza nieudane wyszukanie

Pusta lub nieudana odpowiedź puli nie powinna po cichu usuwać metadanych proxy i zezwalać na bezpośrednie żądanie. Wybierz wyraźny wynik: czekanie w ramach budżetu zadania, niepowodzenie albo użycie zatwierdzonego endpointu z cache.

Utrzymuj też wolną własną trasę API puli. Jeśli to usługa wewnętrzna, wysyłanie jej prywatnej nazwy hosta przez dokładnie ten proxy, który pomaga go wybrać, może stworzyć zależność cykliczną.

Gdy wykrywanie działa bez blokowania niezwiązanej pracy, zbadaj zwykłą transakcję proxy. To osobne naprawy, a ich pomiar zasługuje na osobne pola w logu.