მიეცით თითოეულ aiohttp პროქსის საკუთარი პარალელურობის ბიუჯეტი

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

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

limits = {proxy: asyncio.Semaphore(4) for proxy in proxy_urls}

async def fetch(session, proxy, url):
    async with limits[proxy]:
        async with session.get(url, proxy=proxy) as response:
            return await response.read()

ეს ესკიზი ვარაუდობს, რომ asyncio იმპორტირებულია და პროქსის URL-ები ვალიდირებულია. დაშვებულ საჯარო პროქსის მარშრუტზე საჯარო მოთხოვნებისთვის HTTP პროქსების სია გვთავაზობს კანდიდატებს aiohttp-ის პროქსის URL-ებისთვის. რეალურმა აპლიკაციამ ასევე უნდა დააყენოს საკუთარი მოთხოვნის ვადა და გადაწყვიტოს, რამდენი პასუხის მონაცემი სჭირდება. დიდი ფაილის მთლიანად მეხსიერებაში წაკითხვა ცალკე რესურსული გადაწყვეტილებაა.

შეინახეთ ნებართვა ძვირი ნაწილისთვის

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

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

კავშირის ლიმიტები სხვა კითხვას პასუხობენ

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

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

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

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