Wynik testu uznajemy za dowód dopiero wtedy, gdy razem z liczbą publikujemy środowisko, protokół, surowy plik z narzędzia i jawną drogę od danych do werdyktu. Liczba dotyczy zapisanych warunków. Nie dowodzi SLA, jakości supportu ani wydajności innego planu tego samego dostawcy.

Nie znajdziesz tu zwycięzców, ocen ani cen. Ta strona jest kontraktem między nami a tobą: opisuje reguły, według których powstaje każdy nasz pomiar, i granice, poza które nie wolno nam wyprowadzić wniosku z liczby. Bez opublikowania tych reguł żaden ranking w tym serwisie nie może się ukazać - i przy każdym zestawieniu możesz nas z nich rozliczyć.

Po czym poznasz, że liczbie można ufać?

Weź dwa testy tego samego planu VPS. Przykład jest wymyślony, ale składa się z decyzji, które podejmuje każdy, kto mierzy serwery.

Pierwszy pomiar ruszył w dzień roboczy, z generatorem ruchu w tej samej serwerowni co badana maszyna. Drugi odbył się w nocy, z generatorem na innym kontynencie i z nowszą wersją narzędzia. Oba zwróciły "czas odpowiedzi". Każdy inny.

Żaden z tych pomiarów nie kłamie - każdy opisuje własne warunki. Kłamstwo zaczyna się dopiero w zdaniu "ten VPS jest szybszy", które te warunki przemilcza. Dlatego u nas warunki podróżują razem z liczbą: co obciążało maszynę, czym, skąd i kiedy. Jeśli przy wyniku tego nie widzisz, nie pozwól, żeby ten wynik cokolwiek rozstrzygał. Dotyczy to także naszych tabel.

Co uznajemy za dowód?

Dowód nie siedzi w tekście, tylko w artefakcie, do którego tekst odsyła. Rozdzielamy trzy klasy informacji i pilnujemy, żeby żadna nie udawała innej:

  1. Dowód pierwotny - publiczny surowy wynik pomiaru spięty z protokołem i zapisem środowiska. Musi dać się otworzyć, przeliczyć i porównać z tym, co napisaliśmy. Gdy artefakt przestaje działać, wynik przestaje być dowodem, nawet jeśli kiedyś nim był.
  2. Wynik przetworzony - wartość, która trafia do tabeli albo zdania w artykule. Zawsze towarzyszy jej jawna kalkulacja prowadząca od danych surowych do tej właśnie liczby. Jeśli tej drogi nie da się odtworzyć, wartość nie wchodzi do tekstu.
  3. Deklaracja producenta - parametr z dokumentacji, regulaminu albo SLA. Cytujemy go ze źródłem i datą, ale nigdy nie przedstawiamy jako własnego pomiaru. Deklaracja opisuje zobowiązanie dostawcy, pomiar opisuje zachowanie środowiska - masz widzieć, którą z tych rzeczy właśnie czytasz.

Opinia użytkownika i materiał marketingowy podpowiadają, co warto zmierzyć. Same wynikiem nie są.

Każdy wniosek ma zakres nie szerszy niż badany workload, czyli sposób obciążenia maszyny podczas pomiaru, i badane środowisko. Pomiar jednego planu nie ocenia marki, pomiar jednego regionu nie ocenia sieci dostawcy, a pomiar jednego endpointu nie ocenia całej aplikacji.

Co zapisujemy, zanim ruszy pierwszy pomiar?

Kartę środowiska wypełniamy przed testem, bo opis sporządzany po fakcie pomija to, co po drodze zmieniliśmy. Zapisujemy:

  • operatora i nazwę planu w brzmieniu z oferty;
  • region usługi oraz miejsce uruchomienia generatora ruchu;
  • datę, godzinę i strefę czasową pomiaru;
  • system, obraz, wersję jądra, runtime i wersje narzędzi pomiarowych;
  • udostępnione parametry planu i zadeklarowany zakres zarządzania;
  • konfigurację workloadu, zbiór danych i stan początkowy środowiska;
  • każdą zmianę wykonaną przed testem, także w konfiguracji domyślnej.

Nie wpisujemy na tej stronie przykładowych wersji ani parametrów. Przykład wstawiony dla ilustracji zaczyna z czasem żyć własnym życiem i bywa cytowany jako wynik. Test kompletności karty jest jeden: jeśli po jej przeczytaniu nie umiesz odtworzyć układu, w którym powstał pomiar, karta jest niekompletna.

Dlaczego protokół powstaje przed wynikiem?

Protokół testu to zapisany z góry plan pomiaru: pytanie testowe, metryka, która na nie odpowiada, warunek zaliczenia dający odpowiedź "tak" albo "nie", reguła przerwania na wypadek błędu środowiska oraz kolejność czynności od przygotowania po zebranie artefaktów. Powstaje, zanim zobaczymy pierwszy rezultat. Metryka dobrana po obejrzeniu wyniku przestaje być pomiarem i staje się uzasadnieniem tezy przyjętej z góry.

Zmiana protokołu po starcie nie poprawia wyniku, tylko otwiera nową serię. Wyników zebranych według różnych reguł nie łączymy w jednej tabeli, nawet gdy różnica wygląda na drobną.

Tam, gdzie narzędzie na to pozwala, warunek zaliczenia zapisujemy maszynowo. W k6 robi to threshold, czyli kryterium pass albo fail zdefiniowane dla metryki; niespełnienie progu kończy proces niezerowym kodem wyjścia (dokumentacja Grafana k6). Werdykt nie zależy wtedy od tego, jak ktoś odczytał wykres.

Jak wygląda karta testu?

Karta testu to komplet informacji publikowany z każdą wartością, która wpływa na werdykt: identyfikator, środowisko, protokół, surowy artefakt, kalkulacja i zakres wniosku. Jedna wartość dostaje jedną kartę i jeden identyfikator, a każda liczba w tekście rankingu odsyła do swojej karty.

Pole karty testu Co zapisujemy Reguła i granica
Identyfikator oznaczenie testu, do którego odsyła każda liczba w tekście wartość bez identyfikatora nie może trafić do rankingu
Środowisko operator, system, obraz, konfiguracja maszyny i stan początkowy opis powstaje przed pomiarem, nie po nim
Plan i region nazwa planu z oferty oraz lokalizacja usługi i generatora ruchu wynik dotyczy tego planu i regionu, nie oferty dostawcy jako całości
Czas data, godzina i strefa czasowa wykonania bez czasu wynik traci porównywalność z późniejszymi seriami
Workload co dokładnie obciąża środowisko i na jakich danych workload jest częścią wyniku, nie tłem dla niego
Wersje wersje systemu, runtime i każdego narzędzia pomiarowego zmiana wersji narzędzia tworzy nowy kontekst testu
Protokół pytanie testowe, metryka, warunek zaliczenia i reguła przerwania zapisany przed poznaniem wyniku, bez późniejszej korekty
Surowy artefakt plik wyniku narzędzia w formacie, który da się otworzyć i przeliczyć publiczny i trwały; utrata artefaktu odbiera wynikowi rolę dowodu
Kalkulacja droga od danych surowych do wartości pokazanej w tekście jawna i odtwarzalna krok po kroku, łącznie z metodą agregacji
Wynik wartość z jednostką i rozrzutem między wykonaniami pojedyncza liczba bez rozrzutu nie opisuje pomiaru
Zakres wniosku co ten wynik potwierdza i czego nie potwierdza zakres nie może być szerszy niż zapisane warunki
Status wynik ważny, błąd testu, brak danych, wynik nieporównywalny albo wycofany stany są rozłączne; brak danych nie zamienia się w zero

Reguły punktacji opisujemy prozą i pokazujemy w polu kalkulacji odpowiedniej karty. Nie dokładamy osobnych tabel punktowych - każda kolejna tabela oddala liczbę od jej artefaktu.

Ile wykonań składa się na wynik?

Pojedyncze wykonanie nie jest serią, a średnia bez rozrzutu nie jest wynikiem. Ten sam wariant testu zachowuje workload, konfigurację, lokalizację generatora ruchu i wersje narzędzi; zmiana któregokolwiek z tych elementów otwiera nową serię.

Zachowujemy wynik każdego wykonania, nie tylko podsumowanie. Podsumowanie odtworzysz z wykonań, ale operacji odwrotnej nie wykona nikt - a to właśnie rozrzut między wykonaniami mówi, czy pomiar jest stabilny. W karcie opisujemy kolejność wykonań, rozgrzewkę, przerwy oraz przyczynę każdego odrzuconego wykonania. Odrzucenie bez zapisanej przyczyny znosi różnicę między pomiarem a doborem danych pod tezę, więc jest niedopuszczalne.

Liczby powtórzeń nie narzucamy z góry. Wynika z protokołu konkretnego badania i z rozrzutu obserwowanego w danym środowisku, a metodę agregacji deklarujemy przed analizą - wszystko trafia do karty tego testu.

Co mierzymy przy obciążeniu webowym?

Przy obciążeniu aplikacji webowej mierzymy czas obsługi żądania widziany przez generator ruchu i zawsze nazywamy dokładną metrykę narzędzia. W k6 http_req_duration obejmuje łączny czas wysyłania, oczekiwania i odbierania dla żądania HTTP, a nie obejmuje czasu blokowania ani nawiązywania połączenia (dokumentacja Grafana k6). Przy porównywaniu wyników z różnych narzędzi ta różnica potrafi przesądzić o werdykcie, dlatego nazwa metryki trafia do karty razem z wartością.

Obok czasu obsługi zapisujemy liczbę zakończonych żądań oraz błędy według kryterium z protokołu. Z góry ustalamy, czy błędem jest wyłącznie brak odpowiedzi, czy również odpowiedź z określonym kodem.

Publikujemy rozkład wyniku, nie samą średnią. Średnia ukrywa ogon rozkładu, a w ogonie siedzą żądania decydujące o tym, jak użytkownik odbiera usługę. Duży rozrzut między wykonaniami przy niezmienionym środowisku jest informacją o środowisku, nie szumem do uśrednienia.

Odpowiedź jednego endpointu nie jest stanem całej aplikacji. Wniosek dotyczy tej ścieżki, tego zestawu danych i tych warunków, w których pomiar wykonano.

Jak mierzymy dysk i sieć?

Dysk mierzymy narzędziem fio, które generuje zadany wzorzec operacji wejścia-wyjścia i raportuje między innymi przepustowość, IOPS oraz opóźnienia; znaczenie wyniku zależy od parametrów zadania (dokumentacja fio). Sama liczba bez tych parametrów nie znaczy nic, więc w karcie zapisujemy wzorzec operacji, rozmiar danych, tryb odczytu lub zapisu i współbieżność. Artefaktem jest wynik w formacie JSON, zachowany razem z wersją narzędzia i definicją zadania.

Sieć mierzymy narzędziem iperf3 - klient i serwer aktywnie mierzą osiągalną przepustowość sieci IP, a kierunek, protokół i czas testu są częścią wywołania (dokumentacja ESnet iperf3). Zapisujemy kierunek transmisji, oba końce trasy, protokół transportowy oraz wynik po stronie klienta i serwera, jeśli narzędzie je udostępnia. Plik JSON z przebiegu zachowujemy jako artefakt.

Wynik dotyczy badanego wzorca i badanej trasy. Nie rozciągamy go na wszystkie operacje dyskowe, wszystkie rozmiary bloku ani wszystkie lokalizacje sieciowe dostawcy.

Jak powstaje werdykt rankingu?

Kryteria i ich wpływ na werdykt publikujemy przed wynikami. Ta kolejność zamyka najprostszą furtkę manipulacji zestawieniem, czyli dobór wag po tym, gdy już widać, kto wygrywa.

Każdy punkt w rankingu wskazuje źródłową kartę testu i jawną kalkulację. Punkt bez karty jest oceną redakcyjną, a takich w rankingu technicznym nie publikujemy.

Brak danych nie staje się zerem, dopóki nie ma na to zapisanej reguły. Zero jest wynikiem pomiaru, brak danych jego nieobecnością - pomieszanie obu przesuwa pozycje w tabeli bez żadnego dowodu. Remis zostaje remisem, jeśli protokół nie daje podstaw do rozstrzygnięcia - nie dobieramy dodatkowego kryterium po to, żeby wyłonić jedno pierwsze miejsce.

Afiliacja, wysokość prowizji i relacja handlowa nie są kryterium technicznym i nie wpływają na kolejność. Ta strona nie zawiera linków afiliacyjnych ani rekomendacji produktów, a w rankingu obecność linku handlowego przy pozycji nie zmienia ani wyniku pomiaru, ani miejsca w zestawieniu.

Czego nie mierzymy?

Lista wyłączeń jest częścią metodologii na tych samych prawach co lista pomiarów. Zobaczysz ją także przy każdym wyniku, którego dotyczy, nie tylko w tym miejscu. Nie mierzymy:

  • dostępności deklarowanej jako SLA - krótki benchmark nie mierzy zobowiązania umownego rozliczanego w skali roku;
  • jakości supportu - pojedynczy kontakt nie jest próbą, z której wolno wnioskować o obsłudze klienta;
  • odporności na DDoS ani pełnego bezpieczeństwa produktu - to osobne dziedziny, wymagające innego badania i innych uprawnień;
  • zgodności prawnej twojej organizacji - do tej oceny potrzeba właściwego aktu, organu i analizy przypadku, nie parametrów usługi;
  • niezawodności innego planu, regionu lub czasu niż zapisane w karcie testu - wynik nie przenosi się na sąsiednią ofertę tego samego dostawcy;
  • wpływu środowiskowego bez pomiaru wykonanego według uznanej metody;
  • łatwości obsługi wyrażonej jako liczba techniczna - bez badania z udziałem użytkowników taka liczba jest oceną, nie pomiarem.

Ta lista skraca zakres tego, co możemy o dostawcy napisać. Skraca też zakres tego, co musielibyśmy później odwoływać - i świadomie wybieramy to drugie.

Kiedy wynik powtarzamy albo wycofujemy?

Zmiana planu, regionu, runtime, wersji narzędzia albo workloadu tworzy nowy kontekst testu. Wynik ze starego kontekstu nie przechodzi do nowego po cichu - powstaje nowa seria z własną kartą. Powtórzenie testu uruchamia materialna zmiana po stronie usługi albo wykryty błąd, nie sam upływ czasu; stałego kalendarza ważności wyników nie prowadzimy.

Błąd protokołu wycofuje wynik. Nie poprawiamy liczby w tabeli po cichu: korekta zachowuje datę, opis zmiany, poprzedni status i poprzedni artefakt, żebyś mógł ustalić, co dokładnie się zmieniło. Historia zmian jest częścią dowodu, nie zapleczem redakcyjnym.

Gdy źródłowy plik przestaje być dostępny, karta dostaje status wycofany, a oparta na niej wartość znika z rankingu. Wynik bez działającego artefaktu nie podpiera już żadnego werdyktu.

Pytania o metodologię

Co uznajecie za dowód w teście hostingu lub VPS?

Komplet spięty jednym identyfikatorem: kartę środowiska, protokół ustalony przed pomiarem, publiczny surowy artefakt narzędzia i jawną kalkulację prowadzącą do wartości pokazanej w tekście. Wartość bez tego kompletu nie wchodzi do rankingu, nawet jeśli pasuje do naszych oczekiwań.

Czy deklaracja producenta może być wynikiem testu?

Nie. Parametr z dokumentacji, regulaminu albo SLA cytujemy jako deklarację dostawcy, ze wskazaniem źródła i daty sprawdzenia. Nie przedstawiamy go jako pomiaru i nie wliczamy do punktacji technicznej. Deklaracja opisuje zobowiązanie, pomiar opisuje zachowanie środowiska w zapisanych warunkach.

Ile razy powtarzacie test?

Tyle, ile przewiduje protokół konkretnego badania. Liczbę wykonań, metodę agregacji i regułę odrzucania wykonań ogłaszamy przed analizą, a nie po niej. Jednej stałej dla wszystkich testów nie ma, bo potrzebna liczba zależy od rozrzutu obserwowanego w danym środowisku i od badanej metryki.

Czy jeden benchmark potwierdza SLA i niezawodność hostingu?

Nie. Benchmark opisuje zachowanie zapisanego workloadu w zapisanym środowisku i czasie. SLA jest zobowiązaniem umownym rozliczanym w innej skali i wymaga innego rodzaju dowodu. Z krótkiego pomiaru nie wyprowadzamy też wniosków o bezpieczeństwie, supporcie ani niezawodności długoterminowej usługi.

Co robicie, gdy test zakończy się błędem?

Zachowujemy artefakt, nadajemy karcie status błędu testu i opisujemy decyzję o powtórzeniu. Błąd nie zamienia się automatycznie w wynik produktu ani w zero w tabeli. Jeśli przyczyna leży w naszym protokole, poprawiamy protokół, a pomiary wykonane według poprzedniej wersji tworzą osobną serię.

Czy afiliacja wpływa na kolejność rankingu?

Nie. Prowizja i relacja handlowa nie są kryterium technicznym i nie zmieniają ani wyniku pomiaru, ani miejsca w zestawieniu. Obecność linku handlowego oznaczamy przy elemencie, ale punktacja i kolejność zostają bez zmian. Ta strona nie zawiera linków afiliacyjnych ani rekomendacji produktów.

Kiedy wynik jest wycofywany?

Po wykryciu błędu protokołu, po utracie źródłowego artefaktu albo po zmianie, która unieważnia zakres wniosku - na przykład zmianie planu lub regionu. Karta dostaje wtedy status wycofany, a oparta na niej wartość znika z rankingu. Korekta pozostaje jawna i zachowuje datę oraz opis zmiany.

Podstawa techniczna

  • Metryka czasu żądania - dokumentacja Grafana k6, Built-in metrics, https://grafana.com/docs/k6/latest/using-k6/metrics/reference/.
  • Progi zaliczenia jako kryterium pass lub fail - dokumentacja Grafana k6, Thresholds, https://grafana.com/docs/k6/latest/using-k6/thresholds/.
  • Wzorzec operacji wejścia-wyjścia i raportowane wielkości - dokumentacja fio, https://fio.readthedocs.io/en/latest/fio_doc.html.
  • Format wyniku fio - dokumentacja fio, sekcja Output, https://fio.readthedocs.io/en/latest/fio_doc.html#output.
  • Aktywny pomiar osiągalnej przepustowości sieci IP oraz format wyniku - dokumentacja ESnet iperf3, https://software.es.net/iperf/invoking.html.

Zakres tej strony

Ta strona odpowiada na jedno pytanie: skąd bierze się werdykt i gdzie kończy się dowód. Dobór architektury i środowiska omawiają zasady doboru środowisk serwerowych, a naprawę błędów napotkanych podczas testów prowadzą runbooki w dziale błędów - metodologia zapisuje błąd i status pomiaru, ale nie przejmuje procedury naprawczej. Wyniki, ceny i rekomendacje produktów pojawią się wyłącznie na przyszłych stronach rankingowych, po spełnieniu warunków opisanych tutaj.