Identyfikacja problemów z wydajnością zazwyczaj oznacza skupienie się na jednej z trzech kategorii: liczba klatek na sekundę (obliczenia), pamięć lub czas ładowania.
Roblox ma szereg narzędzi do identyfikacji problemów z wydajnością, z których część jest dostępna w kliencie Roblox (a zatem w Studio), a część jest dostępna tylko w Studio. Podczas gdy możesz bezpośrednio obserwować zachowanie klienta, musisz używać narzędzi do diagnozowania problemów z serwerem.
Narzędzia diagnostyczne
| Narzędzie | Opis | Lokalizacja | Skrót klawiaturowy | Środowisko |
|---|---|---|---|---|
| Konsola dewelopera | Konsola z wiadomościami dziennika w czasie rzeczywistym, błędami i szczegółowymi informacjami na temat pamięci, sieci i wydajności skryptów. Jest przydatna do przeglądania zużycia pamięci, kluczowych statystyk zdrowia serwera, statystyk wydajności skryptów oraz uruchamiania MicroProfilera klienta lub serwera. | Studio W Grze | F9 | Testowanie w Studio Sesje na żywo |
| MicroProfiler | Narzędzie do debugowania, które rozkłada, ile czasu obliczeniowego jest spędzane na zadaniach w każdej klatce. Może generować zrzuty do analizy, pokazując dokładny podział poszczególnych klatek, co jest pomocne w identyfikacji konkretnego zadania powodującego problemy z wydajnością. Możesz uruchomić profiler zarówno na kliencie, jak i na serwerze, w zależności od tego, która strona ma problem. | Studio W Grze | CtrlAltF6 (⌘⌥F6) | Testowanie w Studio Sesje na żywo |
| Analiza sceny | Zapewnia porównawcze informacje o zasobach używanych przez sceny klienta i serwera oraz które instancje są odpowiedzialne za to zużycie zasobów. | Studio | N/A | Testowanie w Studio |
| Statystyki wydajności | Pasek narzędzi z podstawowymi statystykami wydajności, w tym zużyciem pamięci, CPU, GPU, danymi sieciowymi wysyłanymi i odbieranymi oraz czasem ping. | W Grze | CtrlAltF7 (⌘⌥F7) | Testowanie w Studio Sesje na żywo |
| Statystyki debugowania | Nałożenia z szczegółowymi informacjami na temat grafiki, fizyki, ruchu sieciowego i FPS. | Studio W Grze | ShiftCtrlF1 (Shift⌘F1), ShiftCtrlF2 (Shift⌘F2), ShiftCtrlF3 (Shift⌘F3), ShiftCtrlF4 (Shift⌘F4), ShiftCtrlF5 (Shift⌘F5) | Testowanie w Studio Sesje na żywo |
| Symulacja sieci | Właściwości, które symulują warunki sieciowe w rzeczywistym świecie, takie jak opóźnienie, jitter i utrata pakietów, aby testować połączenia. | Studio | AltS(⌥S) | Testowanie w Studio |
| Panel wydajności | Panel z agregatowymi wykresami zużycia pamięci klienta i serwera, liczby klatek klienta, rytmu serwera i wskaźników awarii w czasie rzeczywistym. Jest pomocny w analizie wzorców wydajności w czasie. Zobacz monitorowanie wydajności. | Panel twórcy | N/A | Sesje na żywo |
Obliczenia serwera
Rytm serwera jest ograniczony do 60 FPS dla wszystkich gier, więc niższe wartości mogą wskazywać na problem z wydajnością. Aby sprawdzić rytm serwera:
Z użyciem Konsoli dewelopera - W zakładce Zadania serwera rozwiń wiersz Rytm i sprawdź wartość Kroków na sekundę, która reprezentuje rytm twojej gry.
Z użyciem MicroProfilera, możesz sprawdzić wykres, aby zobaczyć, czy klatka zajmuje więcej niż 16,67 ms.
MicroProfiler jest szczególnie przydatny do identyfikacji "szczytów" w wydajności, gdzie niektóre klatki zajmują znacznie więcej czasu na przetworzenie niż inne.
Innym objawem obniżonego rytmu serwera jest zwiększone opóźnienie (powszechnie znane jako ping). Im dłużej serwer zajmuje się obliczaniem swoich zadań w każdej klatce, tym dłużej zajmuje przetwarzanie danych sieciowych wysyłanych i odbieranych od klientów. Aby sprawdzić średni ping dla wszystkich graczy połączonych z serwerem, przejdź do zakładki Statystyki serwera w Konsoli dewelopera.
Jeśli rytm serwera pozostaje niski po poprawie wydajności, twoja gra może potrzebować więcej CPU, niż jej serwery otrzymują domyślnie. Możesz zarezerwować więcej z Rozszerzonych usług obliczeniowych.
Obliczenia klienta
Domyślny limit liczby klatek na sekundę klienta wynosi 60 FPS. Jednak użytkownicy mogą podnieść swój limit liczby klatek do 240 FPS na systemie Windows.
Liczba klatek różni się znacznie między urządzeniami. Na przykład, komputer wysokiej klasy może być w stanie "przeforsować" problem obliczeniowy i doświadczyć jedynie nieodczuwalnego spadku liczby klatek. Jeśli testujesz na urządzeniach o niższej wydajności, problemy mają tendencję do bycia bardziej poważnymi i łatwiejszymi do zauważenia.
Aby sprawdzić liczbę klatek w twojej grze:
W kliencie naciśnij ShiftF5, aby wyświetlić podsumowanie statystyk debugowania.
W menu Okno ⟩ Wydajność w Studio włącz Statystyki, aby aktywować statystyki debugowania.
Statystyki wydajności w Studio są zniekształcone przez aplikację Studio, więc powinieneś sprawdzić liczbę klatek w kliencie, aby uzyskać dokładne liczby.
Z użyciem MicroProfilera, możesz sprawdzić wykres, aby zobaczyć, czy klatka zajmuje więcej niż 16,67 ms.
Podczas oceny liczby klatek, pomocne może być ustawienie jakości grafiki na maksymalną wartość, aby usunąć wpływ menedżera liczby klatek. W kliencie otwórz menu, kliknij Ustawienia, zmień Tryb grafiki na ręczny i zwiększ jakość grafiki.
Pamięć serwera
Staraj się utrzymać zużycie pamięci serwera poniżej 50%. Całkowita pamięć serwera używa następującego wzoru:
6.25 GiB + (100 MiB * największa_liczba_połączonych_graczy)
Te liczby używają potęg liczby 2, więc 1 GiB odnosi się do 2^30 bajtów, a 1 MiB do 2^20 bajtów.
Na przykład, serwer z 30 połączonymi graczami ma około 9.18 GiB całkowitej pamięci. Serwery zyskują pamięć, gdy gracze się łączą, ale nie tracą jej, gdy gracze się rozłączają. Jeśli 10 graczy odejdzie, serwer nadal ma 9.18 GiB pamięci, zamiast zmniejszać się do 8.2 GiB.
Gdy serwery są wyłączane (na przykład, gdy są puste lub w ramach procesu aktualizacji), ich zamienniki zaczynają z podstawową ilością pamięci i zaczynają zwiększać ją w miarę łączenia się graczy.
Pamięć klienta
Istnieje kilka sposobów na sprawdzenie zużycia pamięci w grze:
- Otwórz Konsolę dewelopera i przejdź do zakładki Pamięć. Ta zakładka daje podział na to, jak pamięć jest alokowana. Użyj klienta zamiast Studio, aby uzyskać najdokładniejsze odczyty.
- Włącz widok Statystyki wydajności z menu ustawień w kliencie, aby zobaczyć nakładkę z całkowym zużyciem pamięci klienta.
Wysokie zużycie pamięci niekoniecznie wskazuje na problem, ale niektóre oznaki, że może być konieczne dalsze badanie, to:
- Znaczący procent awarii klienta widoczny w Panelu wydajności, szczególnie nagły wzrost, który zbiegł się z aktualizacją. Pewna liczba awarii jest oczekiwana, ale powinieneś zbadać, jeśli wskaźniki awarii wzrosną powyżej 2-3%.
- Awaria występuje podczas testowania na urządzeniu, które chcesz, aby twoja gra obsługiwała.
Znacząca część zużycia pamięci gry na kliencie pochodzi z zasobów, takich jak obrazy, siatki i pliki audio, załadowane do pamięci. W Konsoli dewelopera sprawdź następujące etykiety w sekcji PlaceMemory:
- GraphicsMeshParts - Pamięć graficzna zużywana przez siatki.
- GraphicsTexture - Pamięć graficzna zużywana przez tekstury.
- Sounds - Pamięć zużywana przez pliki audio.
Czasy ładowania
Czas ładowania, zwany również czasem dołączenia, to całkowity czas od momentu, gdy gracz kliknie Graj, do momentu, gdy świat się renderuje i mogą zacząć grać. Po połączeniu klienta z serwerem, dołączenie odbywa się w następującej kolejności:
- ReplicatedFirst replikowane jest do klienta, a wszelkie niestandardowe ekrany ładowania w nim się pojawiają.
- Reszta modelu danych jest replikowana, w tym wszystko w ReplicatedStorage i Workspace. Jeśli włączysz streaming instancji, tylko obszar Workspace w pobliżu punktu spawnu gracza jest replikowany na tym etapie.
- Awatar gracza ładuje się. Czas ładowania kończy się, gdy ekran ładowania znika, a świat zaczyna się renderować.
Wiedza, który krok jest wolny, pomaga wybrać optymalizacje o największym wpływie. Aby uzyskać powszechne przyczyny i rozwiązania, zobacz Popraw wydajność.
Nie ma wbudowanych narzędzi do sprawdzania czasów ładowania, ale ponieważ nie wymagają one precyzji na poziomie milisekund, zazwyczaj wystarczy stoper, aby zrozumieć swoją aktualną bazę i sprawdzić, czy dokonałeś istotnej poprawy. Możesz użyć skryptu klienta w ReplicatedFirst, aby uzyskać pewne pojęcie o tym, jak twoje zmiany wpływają na czasy ładowania, ale ten skrypt nie zapewnia pełnego pomiaru od początku do końca. Rozpoczyna pomiar po replikacji ReplicatedFirst i kończy, gdy początkowa replikacja się kończy, a DataModel.Loaded jest wywoływane, więc nie obejmuje czasu potrzebnego na połączenie z serwerem lub załadowanie awatara:
local startTime = os.clock()
game.Loaded:Connect(function()
local loadTime = os.clock() - startTime
local roundedLoadTime = math.round(loadTime * 10000) / 10000 -- cztery miejsca po przecinku
print("Gra załadowana w " .. roundedLoadTime .. " sekund.")
print("Liczba załadowanych instancji: " .. #workspace:GetDescendants())
end)Aby uzyskać dodatkowe informacje, włącz Drukuj podział rozmiaru dołączenia z zakładki Sieć w Ustawieniach Studio, aby wydrukować 20 największych instancji według rozmiaru oraz procentowy podział według typu instancji, gdy rozpoczynasz grę w Studio.
Jeśli twój czas ładowania jest niespodziewanie wysoki w porównaniu do widocznego rozmiaru twojej gry, sprawdź swoje miejsce pod kątem nieznanych lub zatarczonych skryptów. Niektóre darmowe modele z Sklepu Twórcy zawierają skrypty, które generują tysiące dodatkowych instancji, co dramatycznie zwiększa ilość danych, które muszą być replikowane, gdy gracz dołącza.
Mierz czas ładowania przed i po każdej optymalizacji lub aktualizacji, aby potwierdzić jej wpływ i wychwycić regresje. Nagły wzrost często oznacza, że zawartość została niedawno dodana do ReplicatedStorage lub że zmiana zasobu zwiększyła rozmiar pobierania.
Ping
Dwa główne pomiary pingu (opóźnienia) to ping sieciowy i ping danych.
Ping sieciowy to czas podróży w obie strony mierzony od momentu, gdy klient wysyła pakiet danych sieciowych, do momentu, gdy otrzymuje odpowiedź echa od serwera. Jest podobny do tego, co byłoby zgłaszane jako czas przez ogólny pingowy program narzędziowy.
Ping sieciowy jest widoczny w pasku Statystyki wydajności. Jest głównie wpływany przez długość ścieżki sieciowej między klientem a serwerem i jest poza twoją kontrolą. Możesz jednak symulować ping i inne warunki sieciowe, używając symulacji sieci podczas testowania w Studio.
Ping danych to czas podróży w obie strony mierzony od momentu, gdy klient wysyła dane niezawodnie przez system replikacji, do momentu, gdy otrzymuje odpowiedź echa z systemu replikacji serwera. Obejmuje czas spędzony zarówno w kolejce replikacji klienta, jak i serwera, wraz z retransmisjami TCP podobnymi do utraconych lub uszkodzonych pakietów.
Ping danych jest podobny do wysyłania niezawodnego zdarzenia zdalnego z klienta, odbierania go na serwerze, a następnie wysyłania niezawodnego zdarzenia zdalnego z serwera do klienta w odpowiedzi. Ponieważ ping danych obejmuje również czas spędzony w sieci między klientem a serwerem, jest większy lub równy pingowi sieciowemu.
Średni ping danych dla wszystkich graczy połączonych z serwerem jest widoczny w zakładce Statystyki serwera w Konsoli dewelopera. Ping danych dla pojedynczego klienta jest widoczny, używając ShiftF3, aby wyświetlić statystyki debugowania sieci.
Ping danych jest wpływany zarówno przez ścieżkę sieciową, jak i przez opóźnienia w kolejkach replikacji. Gdy serwer generuje dane replikacji szybciej, niż sieć może je wysłać (lub szybciej, niż klient może je przetworzyć), dane muszą czekać w kolejkach replikacji. Pewna różnica między pingiem danych a pingiem sieciowym jest normalna z powodu retransmisji sieciowych oraz sposobu, w jaki dane sieciowe są przetwarzane przez aplikację Roblox. Jednak jeśli ping danych jest znacznie wyższy niż ping sieciowy, użyj MicroProfilera, aby zobaczyć ruch sieciowy. Aby uzyskać sugestie dotyczące optymalizacji, zobacz sieci i replikację.