რატომ შეიძლება მცირე დაყოვნების მქონე პროქსიმ მაინც ნელა ჩამოტვირთოს

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

რომელი მაჩვენებელი პასუხობს თქვენს კითხვას?

ICMP ping სხვა ტესტია. სერვერმა შეიძლება ping-ს უპასუხოს, როცა პროქსი სერვისი მიუწვდომელია, ან ping დაბლოკოს, როცა პროქსი მუშაობს. პროქსის მისამართამდე ორმხრივი დრო არც პროქსის თქვენს დანიშნულების სერვერთან კავშირს მოიცავს.

გაზომეთ რეალური გადაცემა

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

curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 30 --silent --show-error --output /dev/null --write-out 'status=%{http_code} bytes=%{size_download} average_Bps=%{speed_download} seconds=%{time_total}\n' https://example.com/test-file.bin

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

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

შეინარჩუნეთ თანაბარი პირობები

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

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

აირჩიეთ დატვირთვის მიხედვით

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

ProxyHub-ის პროქსიების სია თითოეული IP-სთვის გამტარუნარიანობის დამოუკიდებელ გაზომვებს არ იძლევა. პროტოკოლის ან ქვეყნის ფილტრი სიჩქარის რეიტინგი არ არის.