Jak zmierzyć jakość mobilnego proxy: 7 metryk, protokół i skrypty

Wprowadzenie: dlaczego jedna liczba prędkości niczego nie rozstrzyga

Wyobraź sobie, że wybierasz mobilne proxy i widzisz piękny napis: prędkość 50 megabitów. Brzmi przekonująco, prawda? Ale ta liczba prawie nic nie mówi o tym, jak proxy zachowa się w rzeczywistej pracy. Prędkość to tylko jeden aspekt jakości, i to nie najważniejszy. Znacznie częściej ludzi zawodzi nie wolne łącze, ale niestabilność: proxy raz odpowiada błyskawicznie, a raz wisi kilka sekund.

W tym poradniku nauczysz się mierzyć jakość mobilnego proxy uczciwie i systematycznie. Opanujesz siedem kluczowych metryk, otrzymasz gotowe skrypty w bash i Python, poznasz jednolity protokół pomiaru i nauczysz się poprawnie interpretować wyniki. Na końcu będziesz w stanie zebrać dane w jedną tabelę i obiektywnie porównać dwóch dostawców.

Co zyskasz w rezultacie: własną metodologię testowania, gotowe narzędzia i zrozumienie, które liczby są alarmujące. Przestaniesz wierzyć reklamowym cyfrom i zaczniesz opierać się na własnych pomiarach.

Dla kogo jest ten poradnik: dla tych, którzy kupują lub już używają mobilnych proxy i chcą wiedzieć, za co płacą. Jest odpowiedni dla początkujących, ponieważ każdy krok jest szczegółowo wyjaśniony. Są też elementy dla zaawansowanych: percentyle, długie przebiegi, interpretacja rozkładów.

Co trzeba wiedzieć wcześniej: wystarczy umieć otworzyć terminal i kopiować polecenia. Doświadczenie programistyczne nie jest wymagane. Wszystko, co będzie potrzebne, wyjaśnimy po drodze.

Ile czasu to zajmie: podstawowe pomiary zajmą około dwóch–trzech godzin. Pełny, całodobowy przebieg trwa oczywiście 24 godziny, ale działa w tle i nie wymaga ciągłej uwagi. Na czytanie i konfigurację zarezerwuj jeden spokojny wieczór.

Dlaczego pojedynczy pomiar niczego nie udowadnia. Sieć komórkowa żyje własnym życiem. W jednej sekundzie wieża jest wolna, w następnej przeciążona. Jeśli wykonasz jedno zapytanie i okaże się szybkie, to przypadek. Prawdziwy obraz daje tylko seria kilkudziesięciu czy setek pomiarów rozłożonych w czasie. Dlatego właśnie będziemy mierzyć nie pojedynczo, ale seriami, i patrzeć nie na średnią, ale na rozkład.

Przygotowanie wstępne: narzędzia i jednolity protokół

Zanim zaczniesz naciskać przyciski, skompletuj zestaw roboczy. Dobre przygotowanie gwarantuje, że twoje liczby będą porównywalne między sobą.

Niezbędne narzędzia

• curl – narzędzie do wysyłania zapytań z wiersza poleceń. W większości systemów jest już zainstalowane.
• Python w wersji 3.8 lub nowszej – do skryptu, który liczy metryki i percentyle.
• Terminal – wiersz poleceń twojego systemu operacyjnego.
• Edytor tekstu – do zapisywania skryptów i notatek.
• Dostęp do proxy – adres, port, login i hasło do twojego mobilnego proxy.

Jak sprawdzić, czy wszystko jest zainstalowane

1. Otwórz terminal.
2. Wpisz polecenie curl --version i naciśnij Enter.
3. Jeśli zobaczysz numer wersji, curl jest gotowy.
4. Wpisz python3 --version i naciśnij Enter.
5. Jeśli zobaczysz coś w rodzaju Python 3.11, wszystko w porządku.

Wskazówka: jeśli python3 nie został znaleziony, pobierz Pythona z oficjalnej strony producentów. Podczas instalacji w Windows pamiętaj o zaznaczeniu opcji „Add Python to PATH”, w przeciwnym razie terminal nie zobaczy polecenia.

Zestaw referencyjnych endpointów

Endpoint – to adres, do którego wysyłamy zapytania. Niezwykle ważne jest wybieranie rzeczywistych celów, podobnych do tych, z którymi będziesz pracować. Nie testuj proxy tylko na specjalnych serwerach do pomiaru prędkości – nie odzwierciedlają one rzeczywistego obciążenia.

Przygotuj trzy–cztery różne adresy. Na przykład stronę do sprawdzania adresu IP, lekką stronę tekstową oraz jeden–dwa zasoby, z którymi planujesz pracować. Różne cele dają różny obraz i to normalne.

⚠️ Uwaga: używaj tylko tych zasobów, do których dostęp jest dozwolony przez ich regulamin i nie narusza prawa. Nie używaj proxy ani skryptów testowych do działań sprzecznych z prawem lub warunkami korzystania z usług.

Jednolity protokół pomiaru

Aby porównanie było uczciwe, ustal warunki i nie zmieniaj ich między testami różnych dostawców.

• Ustalona pora dnia. Mierz oba proxy w tym samym przedziale czasowym. Sieć komórkowa w południe i w nocy zachowuje się inaczej.
• Minimalna liczba przebiegów. Wykonaj serię co najmniej kilkudziesięciu zapytań dla każdej metryki. Im więcej prób, tym bardziej wiarygodny wynik.
• Te same endpointy. Testuj oba proxy na identycznym zestawie adresów.
• Jednakowe ustawienia timeoutów. Ustaw jednolity limit oczekiwania dla wszystkich zapytań.
• Ten sam komputer i łącze. Nie przesiadaj się między urządzeniami w trakcie testu.

Wskazówka: załóż osobny folder dla każdego dostawcy i zbieraj tam logi. Dzięki temu niczego nie pomylisz przy porównaniu.

✅ Sprawdzenie: masz zainstalowane curl i Pythona, przygotowałeś listę endpointów i zapisałeś protokół warunków. Teraz można przejść do teorii.

Podstawowe pojęcia w prostym języku

Omówmy terminy, które będą się pojawiać na każdym kroku. Zrozumienie tych słów to połowa sukcesu.

Opóźnienie

Opóźnienie to czas między wysłaniem zapytania a otrzymaniem odpowiedzi. Mierzone w milisekundach. Im mniej, tym lepiej. Wyobraź sobie, że krzyczysz w górach i czekasz na echo: opóźnienie to przerwa do pierwszego dźwięku.

TTFB

TTFB oznacza czas do pierwszego bajtu (Time To First Byte). To moment, w którym serwer zaczął wysyłać odpowiedź. To najważniejsza część opóźnienia, ponieważ pokazuje, jak szybko proxy i serwer zareagowały na twoje zapytanie, jeszcze przed przesłaniem głównej treści.

Przepustowość

Przepustowość – to ile danych proxy jest w stanie przesłać w ciągu sekundy. To ta prędkość, którą lubią podawać w reklamach. Jest ważna, ale tylko w połączeniu z innymi metrykami.

Dżiter (jitter)

Dżiter – to rozrzut opóźnienia między kolejnymi zapytaniami. Jeśli jedna odpowiedź przyszła po 100 ms, następna po 105, a trzecia po 98, dżiter jest mały i to dobrze. Jeśli wartości skaczą od 80 do 900, dżiter jest ogromny, a praca będzie szarpana.

Odsetek udanych odpowiedzi

To procent zapytań, które zakończyły się sukcesem, bez błędów i przerwań. Metryka ta pokazuje niezawodność. Proxy może być szybkie, ale jeśli co dziesiąte zapytanie upada, praca z nim jest uciążliwa.

Percentyle p50, p95 i p99

To sposób opisania rozkładu wartości. Percentyl p50 to mediana: połowa zapytań jest szybsza od tej wartości, połowa wolniejsza. Percentyl p95 mówi, że 95% zapytań zmieściło się w tym czasie, a 5% było gorszych. Percentyl p99 pokazuje zachowanie najwolniejszych przypadków.

Wskazówka: zapamiętaj główną zasadę. Średnia wartość oszukuje, a percentyle mówią prawdę. Jeśli masz dziewięć szybkich odpowiedzi i jedną zawieszoną na dziesięć sekund, średnia wygląda znośnie, ale p99 od razu wskaże problem.

Czym różni się wolno od niestabilnie

Wolne proxy stabilnie daje duże wartości opóźnienia. To przewidywalne. Niestabilne proxy raz daje świetne, raz fatalne wyniki. Często niestabilność jest gorsza niż jednostajna powolność, bo nie da się jej zaplanować.

✅ Sprawdzenie: rozumiesz, czym są opóźnienie, TTFB, przepustowość, dżiter, odsetek udanych odpowiedzi i percentyle. Świetnie, przechodzimy do praktyki.

Krok 1: mierzymy dostępność i odsetek udanych odpowiedzi

Cel etapu: dowiedzieć się, jak niezawodnie proxy odpowiada na zapytania i zrozumieć, jakie błędy występują.

Co robimy

Wyślemy serię kilkudziesięciu identycznych zapytań i policzymy, ile z nich zakończyło się sukcesem. Przy okazji zbierzemy błędy według typów: timeouty, przerwania połączeń, odpowiedzi z kodami błędów.

Instrukcja krok po kroku

1. Otwórz terminal.
2. Przygotuj ciąg dostępu do proxy w formacie login, hasło, adres i port.
3. Wykonaj serię zapytań za pomocą prostego cyklu, gdzie polecenie curl łączy się z twoim endpointem przez proxy.
4. Dla każdego zapytania zapisz kod odpowiedzi oraz fakt sukcesu lub błędu.
5. Po zakończeniu serii oblicz procent udanych odpowiedzi.

Podstawowe polecenie dla jednego zapytania wygląda tak: curl z flagą proxy, flagą oczekiwania i adresem. Flaga --max-time ogranicza czas oczekiwania, aby zawieszone zapytanie nie zatrzymało całej serii.

Jak interpretować wynik

Podziel odpowiedzi na grupy. Udane – to odpowiedzi z normalnymi kodami. Osobno policz timeouty, gdy serwer nie odpowiedział na czas. Osobno – przerwania połączeń. Osobno – odpowiedzi z kodami błędów serwera.

Uwaga: rozkład błędów jest ważniejszy niż ich ogólna liczba. Jeśli wszystkie awarie to timeouty, problem leży w prędkości lub przeciążeniu sieci. Jeśli to przerwania połączeń, proxy może być niestabilne na poziomie łącza komórkowego.

Wskazówka: nie wyciągaj wniosków na podstawie pięciu zapytań. Minimalna sensowna seria to kilkadziesiąt. Dla ważnej decyzji zrób setki.

Możliwe problemy

• Wszystkie zapytania padają. Sprawdź poprawność loginu, hasła, adresu i portu. Jeden błąd w pisowni psuje wszystko.
• Część zapytań wisi w nieskończoność. Koniecznie użyj ograniczenia czasu, inaczej seria się nie zakończy.
• Skaczą kody błędów serwera. Być może docelowy zasób sam jest niestabilny. Spróbuj innego endpointu dla kontroli.

✅ Sprawdzenie: masz liczbę udanych odpowiedzi, liczbę błędów każdego typu i wiesz, gdzie proxy się potyka.

Krok 2: mierzymy opóźnienie i TTFB przez percentyle

Cel etapu: uzyskać uczciwy obraz opóźnienia, opierając się na rozkładzie, a nie na mylącej średniej.

Dlaczego średnia wprowadza w błąd

Zakładając, że masz dziesięć zapytań. Dziewięć przyszło w 100 ms, a jedno zawisło na pięć sekund. Średnia pokaże około 600 ms, i to będzie kłamstwo w obie strony. W rzeczywistości prawie zawsze proxy jest szybkie, ale czasami katastrofalnie wolne. Percentyle pokazują to uczciwie.

Format wyjścia curl z flagą -w

Narzędzie curl potrafi podać szczegółowy podział czasów. Flaga -w pozwala poprosić o konkretne wskaźniki. Najbardziej przydatne zmienne dla nas to: time_starttransfer – to właśnie TTFB, czas do pierwszego bajtu. Są też time_connect – czas nawiązania połączenia, oraz time_total – całkowity czas zapytania.

1. Złóż polecenie curl z flagą -o aby wysłać treść odpowiedzi w nicość, by nie przeszkadzała.
2. Dodaj flagę -s, aby ukryć wskaźnik postępu.
3. Dodaj flagę -w z potrzebnymi zmiennymi czasu.
4. Uruchom polecenie w pętli odpowiednią liczbę razy przez swoje proxy.
5. Zapisz wszystkie wartości TTFB do pliku, po jednej liczbie na wiersz.

Jak obliczyć percentyle

Zebrane liczby posortuj rosnąco. Wartość na pozycji środka listy – to p50. Wartość na pozycji 95% długości listy – to p95. Wartość na pozycji 99% – to p99. W skrypcie Pythona na końcu poradnika odbywa się to automatycznie.

Wskazówka: zawsze patrz na parę p50 i p95 razem. Jeśli są blisko siebie, proxy jest stabilne. Jeśli jest między nimi przepaść, proxy ma rzadkie, ale bolesne spadki.

Możliwe problemy

• Wartości TTFB są podejrzanie małe. Być może zadziałała pamięć podręczna. Wyłącz ponowne użycie połączenia flagą wyłączającą keep-alive i dodaj unikalny parametr do adresu.
• Wartości znacznie się różnią między uruchomieniami. To normalne w sieci komórkowej. Właśnie dlatego robimy serie, a nie pojedyncze pomiary.

✅ Sprawdzenie: masz plik z wartościami TTFB i trzy liczby percentyli, które opisują rzeczywiste zachowanie opóźnienia.

Krok 3: mierzymy przepustowość uczciwie

Cel etapu: poznać rzeczywistą prędkość transmisji danych bez samooszukiwania się.

Jak zmierzyć uczciwie

Pobierz przez proxy plik o znanym rozmiarze i zmierz, ile czasu to zajęło. Podziel rozmiar przez czas i otrzymasz prędkość. Brzmi prosto, ale są niuanse, które łatwo przeoczyć.

1. Wybierz kilka plików o różnym rozmiarze na rzeczywistych zasobach.
2. Pobierz każdy przez proxy za pomocą curl, mierząc czas flagą -w ze zmienną time_total i zmienną size_download.
3. Powtórz pobieranie kilka razy dla każdego pliku.
4. Oblicz prędkość dla każdego przebiegu i spójrz na rozkład.

Dlaczego kilka plików i endpointów

Jeden plik z jednego serwera może napotkać ograniczenia samego serwera, a nie twojego proxy. Różne źródła dają różny obraz. Jeśli przez wszystkie źródła prędkość jest jednakowo niska, problem leży w proxy. Jeśli się różni, wąskim gardłem może być konkretny serwer.

Wpływ ograniczeń taryfy

Wiele taryf komórkowych ma ograniczenia prędkości lub objętości danych. Po przekroczeniu pewnego progu prędkość może gwałtownie spaść. Uwzględnij to: jeśli pobierzesz dużo danych pod rząd, spowolnienie może być skutkiem taryfy, a nie jakości proxy.

⚠️ Uwaga: nie pobieraj gigantycznych ilości danych na potrzeby testu, jeśli twoja taryfa jest limitowana. Ryzykujesz wyczerpanie pakietu danych. Używaj plików o umiarkowanym rozmiarze.

Wskazówka: mierz przepustowość o tej samej porze dnia, co pozostałe metryki. Obciążenie sieci ma duży wpływ na wynik.

Możliwe problemy

• Prędkość jest niestabilna. To typowe dla sieci komórkowych. Patrz na medianę prędkości, a nie na pojedynczy najlepszy wynik.
• Prędkość gwałtownie spadła w trakcie testu. Być może zadziałał limit taryfy lub zmienił się tryb sieci.

✅ Sprawdzenie: masz wartości prędkości z kilku źródeł i wiesz, gdzie jest wąskie gardło.

Krok 4: mierzymy dżiter i stabilność

Cel etapu: zrozumieć, jak równomiernie działa proxy, a nie tylko jak szybko.

Co robimy

Bierzemy serię pomiarów opóźnienia z poprzednich kroków i patrzymy na rozrzut. Dżiter to w zasadzie miara tego, jak bardzo sąsiednie wartości różnią się od siebie.

1. Weź plik z wartościami opóźnienia zebranymi w drugim kroku.
2. Oblicz różnicę między kolejnymi pomiarami.
3. Uśrednij moduły tych różnic – to będzie oszacowanie dżitera.
4. Dodatkowo spójrz na odchylenie standardowe całej serii.

Co uważać za normę

Nie ma uniwersalnych liczb, ponieważ norma zależy od zadania. Ogólna zasada jest taka: im mniejszy dżiter w stosunku do samego opóźnienia, tym lepiej. Jeśli opóźnienie wynosi 100 ms, a dżiter 5 ms – to doskonale. Jeśli dżiter jest porównywalny z opóźnieniem, praca będzie szarpana.

Wskazówka: zwizualizuj serię pomiarów prostym wykresem. Płaska linia – dobry znak. Piła z ostrymi zębami – niepokojący.

Rozrzut wartości

Zwracaj uwagę na rzadkie odstające wartości. Jeden gwałtowny skok na sto zapytań może być do zaakceptowania. Regularne skoki oznaczają, że proxy jest podatne na wahania sieci komórkowej bardziej niż normalnie.

✅ Sprawdzenie: masz oszacowanie dżitera i wiesz, czy proxy jest stabilne, czy skacze.

Krok 5: sprawdzamy zachowanie przy zmianie IP

Cel etapu: zrozumieć, jak szybko i jak jakościowo proxy zmienia adres IP.

Co mierzymy

Mobilne proxy potrafią zmieniać adres IP na żądanie lub według harmonogramu. Interesuje nas kilka rzeczy: ile trwa zmiana, czy nowy adres pozostaje w tej samej sieci i mieście oraz ile unikalnych adresów uda się zebrać w ciągu godziny.

1. Zapytaj o bieżący adres IP przez endpoint sprawdzania IP.
2. Zainicjuj zmianę IP w sposób przewidziany przez twojego dostawcę.
3. Zmierz czas do momentu, gdy nowy adres stanie się dostępny.
4. Ponownie zapytaj o IP i zapisz je.
5. Powtórz cykl wielokrotnie w ciągu godziny.
6. Policz liczbę unikalnych adresów i czas każdej zmiany.

Jak ocenić wynik

Spójrz na kilka parametrów. Szybkość zmiany pokazuje, jak szybko otrzymujesz świeży adres. Liczba unikalnych adresów w ciągu godziny mówi o różnorodności puli. Przynależność do tej samej sieci i miasta potwierdza, że pozostajesz w oczekiwanym segmencie.

Wskazówka: zapisuj nie tylko sam adres, ale także dane o jego sieci i mieście, które zwraca endpoint sprawdzający. Dzięki temu zobaczysz, czy geografia jest stabilna przy zmianie.

⚠️ Uwaga: używaj zmiany IP tylko w zgodnych z prawem celach i zgodnie z regulaminami usług, z którymi pracujesz. Możliwości techniczne proxy nie uchylają wymogów prawnych i umów użytkownika.

Możliwe problemy

• Zmiana trwa zbyt długo. Sprawdź, czy używasz właściwej metody. Zapytaj dostawcę o standardowy sposób.
• Adresy się powtarzają. Niewielkie powtórzenia się zdarzają, ale ciągłe duplikaty świadczą o małej puli.

✅ Sprawdzenie: masz czas zmiany, liczbę unikalnych adresów w ciągu godziny i dane o ich geografii.

Krok 6: sprawdzamy zgodność geografii i typu połączenia

Cel etapu: upewnić się, że proxy faktycznie odpowiada deklarowanym cechom.

Co sprawdzamy

Dostawca zwykle podaje kraj, region i typ połączenia, np. sieć komórkową. Naszym zadaniem jest porównanie deklaracji z rzeczywistością.

1. Przez proxy skontaktuj się z endpointem, który zwraca dane o twoim adresie.
2. Zapisz określony kraj i region.
3. Zapisz typ połączenia, który określa serwis.
4. Powtórz sprawdzenie kilkakrotnie przy różnych adresach IP.
5. Porównaj wyniki z tym, co obiecał dostawca.

Jak interpretować wynik

Jeśli geografia i typ połączenia są stabilnie zgodne z deklarowanymi – świetnie. Jeśli okresowo pojawiają się inne regiony lub typ połączenia się nie zgadza, to powód do zadania pytań dostawcy.

Wskazówka: sprawdzaj geografię za pomocą kilku niezależnych źródeł geolokalizacji. Bazy danych o przyporządkowaniu adresów czasami się różnią i jedno źródło może się mylić.

✅ Sprawdzenie: potwierdziłeś lub obaliłeś zgodność geografii i typu połączenia z deklaracjami.

Krok 7: uruchamiamy długi przebieg na dobę

Cel etapu: zobaczyć to, czego nie da się zauważyć w pięć minut.

Po co całodobowy przebieg

Krótki test łapie tylko bieżący stan sieci. Całodobowy przebieg pokazuje zachowanie proxy o różnych porach: rano, w godzinach szczytu, w nocy. Zobaczysz, jak zmienia się opóźnienie, odsetek udanych odpowiedzi i stabilność w ciągu dnia.

1. Skonfiguruj skrypt do okresowych pomiarów, np. co kilka minut.
2. Uruchom go w tle i zostaw na 24 godziny.
3. Upewnij się, że wyniki zapisywane są do pliku ze znacznikiem czasu.
4. Po dobie zbierz dane i stwórz obraz według godzin.

Co pokazuje długi przebieg

Zobaczysz spadki w godzinach szczytu, gdy sieć komórkowa jest przeciążona. Zauważysz nocne okna stabilności. Odkryjesz rzadkie fale błędów, które w ciągu pięciu minut po prostu nie zdążyłyby się ujawnić. To właśnie całodobowy przebieg oddziela dobre proxy od przeciętnego.

⚠️ Uwaga: kontroluj zużycie danych podczas całodobowego przebiegu. Wykonuj lekkie zapytania, aby nie wyczerpać limitu taryfy w ciągu doby ciągłej pracy.

Wskazówka: nie uruchamiaj całodobowego przebiegu na komputerze, który może przejść w stan uśpienia. Wyłącz usypianie, w przeciwnym razie pomiary zostaną przerwane.

✅ Sprawdzenie: masz całodobowy log ze znacznikami czasu, który pokazuje zachowanie proxy w dynamice.

Gotowe skrypty do pomiarów

Poniżej znajdują się szablony obliczające opisane metryki. Dostosuj je do swoich danych dostępowych i endpointów.

Skrypt w bash

Ten skrypt wykonuje serię zapytań, zbiera TTFB i kody odpowiedzi, zapisuje je do pliku. Logika jest taka: w pętli wykonuje się curl przez proxy, flaga -w wypisuje czas do pierwszego bajtu i kod odpowiedzi, wynik jest dopisywany do logu.

Główne elementy skryptu: zmienna z adresem proxy w formacie protokół, login, hasło, adres i port. Zmienna z docelowym endpointem. Pętla o zadanej liczbie powtórzeń. Wewnątrz pętli wywołanie curl z flagami -s (cisza), -o (zrzucenie treści), --max-time (ograniczenie czasu oczekiwania) oraz -w ze zmiennymi time_starttransfer i http_code. Każdy wiersz wyniku jest dopisywany do pliku tekstowego. Po pętli bash może obliczyć prostą statystykę lub przekazać plik do Pythona.

Aby wyłączyć pamięć podręczną, dodaj do adresu unikalny parametr zapytania i użyj flagi wyłączającej ponowne użycie połączenia. Zapewni to, że każdy pomiar będzie uczciwy, a nie pobrany z pamięci.

Skrypt w Python

Skrypt w Pythonie jest wygodniejszy do obliczania percentyli i dżitera. Czyta on plik z wartościami lub sam wykonuje zapytania za pomocą biblioteki HTTP obsługującej proxy.

Logika skryptu jest następująca. Najpierw ustawiane są parametry: adres proxy, lista endpointów, liczba powtórzeń i timeout. Następnie w pętli wykonywane są zapytania, dla każdego rejestrowany jest czas do pierwszego bajtu, całkowity czas i kod odpowiedzi. Udane i nieudane odpowiedzi liczone są oddzielnie. Wszystkie wartości opóźnienia gromadzone są na liście.

Po zebraniu danych skrypt sortuje listę opóźnień i oblicza percentyle. Mediana bierze się ze środka posortowanej listy. Percentyl p95 – z pozycji 95% długości. Percentyl p99 – z pozycji 99%. Dżiter jest liczony jako średnia wartości bezwzględnych różnic między kolejnymi pomiarami. Odsetek udanych odpowiedzi to liczba sukcesów podzielona przez całkowitą liczbę zapytań.

Na koniec skrypt wypisuje raport końcowy: odsetek udanych odpowiedzi, percentyle opóźnienia, oszacowanie dżitera oraz rozkład błędów według typów. W przypadku całodobowego przebiegu dodaj znacznik czasu do każdego wpisu i zawiń pomiary w pętlę z przerwą między seriami.

Wskazówka: zapisuj surowe dane, a nie tylko końcowe liczby. Jeśli później będzie trzeba przeliczyć metrykę inaczej, będziesz mieć źródła.

⚠️ Uwaga: przechowuj login i hasło do proxy w osobnym pliku konfiguracyjnym, a nie bezpośrednio w skrypcie, który możesz komuś przypadkiem pokazać.

Jak zebrać wyniki w jedną tabelę

Gdy masz już zebrane dane, ważne jest, aby przedstawić je w czytelny sposób. Jednolita tabela pozwala uczciwie porównać dostawców.

Struktura tabeli końcowej

Zrób tabelę, gdzie wiersze to metryki, a kolumny to dostawcy. Dla każdej metryki podaj wartość i, tam gdzie to właściwe, percentyle. Dzięki temu od razu zobaczysz, kto w czym jest lepszy.

• Odsetek udanych odpowiedzi – procent dla każdego dostawcy.
• TTFB – trzy liczby: p50, p95, p99.
• Przepustowość – mediana prędkości.
• Dżiter – oszacowanie rozrzutu.
• Zmiana IP – czas zmiany i liczba unikalnych adresów w ciągu godziny.
• Geografia i typ połączenia – zgodne z deklaracją czy nie.
• Zachowanie w ciągu doby – czy występują spadki w godzinach szczytu.

Tabela interpretacji metryk

Poniżej słowna tabela w postaci metryka, jak mierzona, co oznacza złą wartość. Nie podajemy konkretnych liczb – normy zależą od zadania.

• Odsetek udanych odpowiedzi. Mierzony serią zapytań i liczeniem sukcesów. Zła wartość: zauważalny odsetek błędów, zwłaszcza przerwań, co oznacza nierzetelność.
• TTFB i percentyle. Mierzone przez curl ze zmienną czasu do pierwszego bajtu na dużej serii. Zła wartość: ogromna różnica między p50 a p99, co oznacza rzadkie, bolesne spadki.
• Przepustowość. Mierzona pobieraniem plików o znanym rozmiarze. Zła wartość: prędkość niepokrywająca twoich potrzeb lub gwałtownie spadająca.
• Dżiter. Mierzony jako rozrzut sąsiednich opóźnień. Zła wartość: dżiter porównywalny z samym opóźnieniem, co oznacza szarpaną pracę.
• Zmiana IP. Mierzona cyklem zmian z pomiarem czasu. Zła wartość: długa zmiana i mało unikalnych adresów.
• Geografia i typ połączenia. Mierzone przez porównanie z endpointem geolokacyjnym. Zła wartość: niezgodność z deklaracją.
• Stabilność dobowa. Mierzona długim przebiegiem. Zła wartość: silne spadki metryk w godzinach szczytu.

Wskazówka: przy porównywaniu nie wyciągaj wniosków na podstawie jednego wiersza. Waż metryki według ich znaczenia dla twojego konkretnego zadania. Dla kogoś kluczowa jest stabilność, dla kogoś innego szybkość zmiany adresu.

Sprawdzenie wyniku: lista kontrolna jakości pomiarów

Zanim zaufasz swoim liczbom, przejdź przez poniższą listę. Gwarantuje to, że pomiary są prawidłowe.

• Każda metryka była mierzona serią, a nie pojedynczym zapytaniem.
• Obaj dostawcy byli testowani o tej samej porze dnia.
• Użyto tych samych endpointów i timeoutów.
• Dla opóźnienia obliczono percentyle, a nie tylko średnią.
• Pamięć podręczna i ponowne użycie połączenia zostały wyłączone tam, gdzie to ważne.
• Testy przeprowadzono na rzeczywistych celach, a nie tylko na serwerach do pomiaru prędkości.
• Przeprowadzono co najmniej jeden całodobowy przebieg.
• Surowe dane zostały zachowane na wypadek przeliczeń.

✅ Sprawdzenie: jeśli wszystkie punkty są odhaczone, twoje wyniki można uznać za solidną podstawę do decyzji.

Typowe błędy pomiarów i ich rozwiązania

Poniżej zebrano najczęstsze potknięcia. Każde opisane jako problem, przyczyna i rozwiązanie.

Błąd pierwszy: pojedynczy przebieg

Problem: wniosek wyciągnięty na podstawie jednego–dwóch zapytań. Przyczyna: chęć szybkiego uzyskania liczby. Rozwiązanie: zawsze wykonuj serię kilkudziesięciu lub setek zapytań i patrz na rozkład.

Błąd drugi: test tylko w godzinach szczytu

Problem: wyniki wydają się fatalne lub, przeciwnie, idealne. Przyczyna: pomiar wykonano w szczycie lub przy minimalnym obciążeniu sieci. Rozwiązanie: mierz o różnych porach i koniecznie przeprowadź całodobowy przebieg.

Błąd trzeci: pomiar do serwerów testu prędkości

Problem: liczby są ładne, ale w rzeczywistej pracy jest inaczej. Przyczyna: specjalne serwery do testów prędkości nie odzwierciedlają rzeczywistych celów. Rozwiązanie: testuj na tych zasobach, z którymi będziesz pracować.

Błąd czwarty: ignorowanie pamięci podręcznej

Problem: opóźnienie podejrzanie małe i stabilne. Przyczyna: odpowiedzi pochodzą z cache, a nie z sieci. Rozwiązanie: dodawaj unikalny parametr do adresu i wyłączaj buforowanie.

Błąd piąty: keep-alive zniekształca obraz

Problem: pierwsze zapytanie wolne, kolejne błyskawiczne. Przyczyna: połączenie jest ponownie wykorzystywane, a kolejne pomiary nie uwzględniają nawiązywania połączenia. Rozwiązanie: dla uczciwego pomiaru wyłącz ponowne użycie połączenia, jeśli chcesz widzieć pełne opóźnienie.

Błąd szósty: porównywanie średniej zamiast percentyli

Problem: dwa proxy wydają się podobne według średniej, ale w praktyce jedno jest wyraźnie gorsze. Przyczyna: średnia ukrywa spadki. Rozwiązanie: porównuj p95 i p99.

Błąd siódmy: różne warunki dla różnych dostawców

Problem: porównanie jest nieuczciwe. Przyczyna: jedno proxy testowano w dzień na jednym endpointcie, drugie w nocy na innym. Rozwiązanie: ściśle trzymaj się jednolitego protokołu.

Dodatkowe możliwości i optymalizacja

Gdy opanujesz podstawową metodologię, możesz pójść głębiej.

Automatyzacja regularnych sprawdzeń

Ustaw skrypt do uruchamiania według harmonogramu, np. codziennie. Dzięki temu będziesz widzieć, czy proxy nie degraduje się z czasem. Zbieraj historię i twórz trend.

Pomiary równoległe

Zaawansowani użytkownicy mogą uruchomić kilka wątków jednocześnie, aby ocenić zachowanie pod obciążeniem. Rób to ostrożnie i zgodnie z regulaminem dostawcy.

Wizualizacja danych

Zbuduj wykresy na podstawie zebranych danych. Wykres opóźnienia w zależności od pory dnia pokaże godziny szczytu. Histogram rozkładu opóźnienia pokaże, czy istnieje długi ogon wolnych odpowiedzi.

Wskazówka: nawet prosty wykres w arkuszu kalkulacyjnym sprawia, że wnioski są o wiele bardziej przekonujące niż kolumna liczb.

Segmentacja według endpointów

Obliczaj metryki osobno dla każdego endpointu. Czasami proxy świetnie działa z jednymi celami, a gorzej z innymi. Ten szczegół pomaga podejmować trafne decyzje.