თუ თითოეული დანიშნულება ერთ პროქსის ანგარიშს იყენებს, ამ ანგარიშის ერთდროული მოთხოვნების დაშვება შეიძლება გაიხარჯოს ყველა იმ დანიშნულებაზე. მხოლოდ დომენის ზღვარი ამ საერთო ბიუჯეტს არ გამოხატავს.

ჰიპოთეტური ანგარიშისთვის, რომელიც მაქსიმუმ 20 ერთდროულ მოთხოვნას უშვებს, დატოვეთ გარკვეული რეზერვი და დააყენეთ crawler-ის გლობალური ჩამომტვირთველის ზღვარი:

CONCURRENT_REQUESTS = 16

ეს საილუსტრაციო განაწილებაა და არა ყველა მომწოდებლისთვის რეკომენდებული მნიშვნელობა. Scrapy CONCURRENT_REQUESTS-ს განსაზღვრავს როგორც ჩამომტვირთველის ერთდროული მოთხოვნების მაქსიმალურ რაოდენობას. დომენის კონტროლი შეიძლება პარალელიზმს კიდევ უფრო ამცირებდეს; ისინი გლობალურ ზედა ზღვარს არ ცვლიან.

გამოთვლაში სხვა crawler-ებიც ჩართეთ. ორ დამოუკიდებელ crawler-ს, რომელთაგან თითოეულს 16 მოთხოვნა აქვს ნებადართული, ერთად შეუძლია გადააჭარბოს 20-ის საერთო დაშვებას. ბიუჯეტი განზრახ გაყავით ან საერთო ზღვარი დააწესეთ იქ, სადაც ეს კლიენტები ხვდებიან.

ასევე გაარკვიეთ, რას ითვლის მომწოდებელი. HTTP მოთხოვნები, ღია TCP კავშირები, აქტიური გვირაბები და მოთხოვნები წამში სხვადასხვა სიდიდეა. მუდმივი კავშირები და მულტიპლექსირება მათ რაოდენობებს გააცალკევებს. ამიტომ მოთხოვნების პარალელიზმის პარამეტრი სრული კავშირის ან სიჩქარის შემზღუდველი არ არის.

შეინარჩუნეთ სამიზნე საიტის ტემპი, როგორც ცალკე შეზღუდვა. დაბალი პარალელიზმი ან ჩამოტვირთვის შეყოვნება მაინც შეიძლება იყოს შესაფერისი ცალკეული დანიშნულებისთვის მაშინაც, როცა პროქსის ანგარიშს გამოუყენებელი სიმძლავრე აქვს.

დაკავშირებული სტატიები