Zanim zaczniesz
Zapisz adres gry, protokół, czas, metodę oraz użyte łącze. Porównaj niezależne połączenia, jeśli to możliwe. Zmiana ochrony wymaga uzgodnionej topologii i danych operatora; port webowy nie reprezentuje automatycznie rzeczywistego ruchu gry.
Mierz właściwe połączenie
Ping, HTTP, TCP i UDP mogą obejmować różne trasy albo przetwarzanie. Opisz test i nie przedstawiaj wyników jako tego samego pingu gry. TCP na porcie 443 opisuje połączenie ze stroną, nie opóźnienie FiveM czy Bedrock UDP. Używaj przydzielonego endpointu i zapisz elementy pośrednie, żeby porównania dotyczyły tej samej usługi i rzeczywistego układu sieci.
Porównaj kilka próbek zamiast najlepszego wyniku. Zachowaj minimalną, centralną wartość i wysokie wartości obok liczby próbek. Różnice i przerwy mogą mieć większe znaczenie niż mała średnia różnica. Oddziel opóźnienie sieciowe od czasu gry na symulację i reakcję.
Rozróżnij RTT i jeden kierunek
RTT obejmuje drogę w obie strony, niekoniecznie po tych samych trasach. Dzielenie przez dwa nie daje wiarygodnego pomiaru w jednym kierunku. Potrzebne są odpowiednia metoda i odniesienie czasowe. Dobrze opisana seria RTT jest często praktyczniejsza od pozornie dokładnej liczby. Notuj godzinę, miejsce i sposób pomiaru oraz to, jaki kierunek albo sumę dróg naprawdę badano.
Połącz pomiary z normalnym połączeniem serwisowym. Zachowaj statystyki sieciowe i kontekst w grze, jeśli są dostępne. Sprzęt pośredni może ograniczać odpowiedzi diagnostyczne podczas przekazywania ruchu; Samo ciche przeskoczenie trasy nie oznacza straty dochodzącej do gracza.
Zapisuj wahania i utratę
Pojedyncza szybka odpowiedź może ukryć dużą zmienność. Zbierz próbki, medianę, odstające wyniki oraz utratę pakietów. Szybkie otrzymane odpowiedzi nie rekompensują automatycznie brakujących. Porównuj spokojne i problematyczne okresy; operatorzy z tego samego kraju mogą się różnić. Jedno łącze nie daje podstaw do gwarancji dla całego kraju. Zachowaj również metodę liczenia brakujących odpowiedzi.
Zachowaj surowe wyniki i awarie zamiast wybierać korzystne wartości. Uwzględnij liczbę prób i okres obserwacji. Krótka linia bazowa pokazuje zachowanie w tym czasie; nie jest to gwarancja stałego opóźnienia ani dostępności.
Uwzględnij chronioną trasę
Filtrowanie, dostarczanie i tunele mogą zmienić drogę do źródła. Dodatkowa odległość i punkty wymiany mają znaczenie; więcej wspólnej przepustowości nie oznacza mniejszego opóźnienia. Podawane 15 Tbps CubixServ nie są obietnicą pingu. Zapytaj o faktyczny przebieg oraz zachowanie podczas incydentu, w tym możliwe zmiany routingu, a nie tylko wynik przy normalnym obciążeniu.
W przypadku tuneli sprawdź także MTU i objawy związane z rozmiarem pakietu. W przypadku serwerów proxy sprawdź limity czasu i połączenia podrzędne. Nie zmieniaj kilku komponentów na raz. Potwierdź legalny ruch przed usunięciem reguły, która przyczynia się do ochrony.
Oddziel sieć od pracy serwera
Przeciążony główny wątek, zablokowane zapytania lub nowe chunki mogą spowalniać grę bez podobnego wzrostu pingu. Mierz CPU, konsolę i profile razem. Minecraft wymaga analizy chunków i efektywnego zasięgu, FiveM zasobów i zdarzeń. Więcej RAM nie naprawia automatycznie CPU lub sieci: zmieniaj potwierdzoną przyczynę i porównuj wyniki, nie tylko subiektywne odczucia graczy.
Jeśli istnieje kompatybilne narzędzie, profiluj podczas spowalniania. Raporty spark Paper mogą identyfikować kosztowną pracę. Powiązane pomiary i kopiowanie konfiguracji przed wprowadzeniem zmian. Kupuj więcej zasobów tylko wtedy, gdy uzasadnia to zaobserwowane ograniczenie.
Dokumentuj odtwarzalne porównania
Używaj podobnych łączy, protokołów i okresów przed i po zmianie. Zachowaj medianę, utratę, skrajne wartości i stan serwera, a wątpliwy wynik powtórz w ograniczonym zakresie. Francja może sprzyjać wielu europejskim połączeniom, ale nie gwarantuje stałej liczby dla kraju. Przekaż pomocy odtwarzalny opis i nie przypisuj każdej zwłoki atakowi bez zgodnych danych sieciowych i aplikacyjnych.
Po naprawie powtórz tę samą metodę i sprawdź normalną sesję. Jedna ulepszona próbka nie pozwala ustalić, czy wszystkie ścieżki są stałe. Opisuj mierzone rynki i połączenia, nie obiecując opóźnień dla całego kraju ani nie myląc bliskości geograficznej z jakością tras.
Co zrobić w Twojej sytuacji
| Sytuacja | Następny krok |
|---|---|
| Tylko jeden gracz ma opóźnienia | Porównaj jego łącze z niezależnym dostępem i zapisz trasę oraz godzinę. |
| Ping stabilny, gra wolna | Badaj główny wątek, zasoby i bazę danych podczas tej samej sesji. |
| Zmiana wraz z ochroną | Porównaj ten sam endpoint i metodę przed i po uzgodnionej modyfikacji. |
Oficjalne źródła
Te źródła opisują wymienione protokoły i ustawienia. Sprawdź dokumentację właściwą dla używanej wersji.