Zacznij od zmierzenia problemu. Niski FPS klienta, długi czas zasobu, zacięcia serwera, oczekiwanie na bazę danych i utrata sieci to różne problemy. Zapisz powtarzalną podstawę przy reprezentatywnej liczbie graczy, zanim usuniesz zasoby lub skopiujesz convary z innego serwera.
Metoda: przejrzano 9 sierpnia 2026 r. w odniesieniu do oficjalnego Cfx.re przewodnik po profilowaniu, polecenia konsoli klienta I komendy serwerowe.
1. Zdefiniuj objaw i podstawę
- FPS jednego gracza spada: odtwórz na tym kliencie i sprawdź monitor zasobów klienta.
- Wszyscy gracze się zacinają: rejestruj ostrzeżenia o zacięciach serwera, czas zasobów, opóźnienia bazy danych i nasycenie procesora hosta.
- Dołączanie jest powolne: sprawdź rozmiar strumieniowanych zasobów, zachowanie pobierania i pracę inicjalizacji.
- Akcje się zacinają: śledź zdarzenie i zapytanie do bazy danych, zamiast obwiniać grafikę.
Zapisz wersję artefaktu, liczbę graczy, aktywne zasoby, trasę testową i znaczniki czasu. Zmieniaj jedną zmienną naraz.
2. Poprawnie używaj resmon i profilera
Otwórz F8 i użyj resmon 1 do szybkiego porównania po stronie klienta. Traktuj to jako wskazówkę, a nie wyrok: czas zależy od tego, co robi gracz. Powtórz tę samą interakcję kilka razy. Aby uzyskać dowody na poziomie kodu, wykonaj przechwycenie profilera podczas powolnej akcji i sprawdź kosztowny zakres lub zdarzenie.
Zachowaj szczegółowy FiveM przewodnik po resmon otwarte podczas testowania.
3. Napraw kod zasobu w wąskim gardle
- Zastąp bezwarunkowe pętle klatka po klatce pracą sterowaną zdarzeniami lub uzasadnionym interwałem oczekiwania.
- Waliduj zdarzenia sieciowe na serwerze i wysyłaj tylko dane, których potrzebuje klient.
- Unikaj wysyłania dużych ładunków, gdy wystarczające jest zdarzenie ukierunkowane.
- Buforuj stabilne wyszukiwania, ale unieważniaj bufor, gdy stan bazowy się zmieni.
- Profiluj przed i po; krótszy kod nie jest automatycznie szybszym kodem.
4. Sprawdź pracę bazy danych
Loguj wolne zapytania z parametrami i miejscami wywołania. Dodawaj indeksy dopiero po potwierdzeniu wzorca zapytania i unikaj powtarzania zapytań w pętlach. Grupuj zapisy, gdy poprawność na to pozwala. Testuj ponowne połączenia, zaplanowane zapisy i akcje szczytowe gospodarki, ponieważ pusta baza danych przejściowa może ukrywać opóźnienia produkcyjne.
5. Budżetuj strumieniowane zasoby
Audytuj nadmiernie duże tekstury, zduplikowane modele i pakiety zasobów, które strumieniują znacznie więcej niż serwer wykorzystuje. Przetestuj czyste dołączenie i ruchliwą lokalizację. Zweryfikuj poziomy szczegółowości, rozdzielczość tekstur i integralność plików przed kompresją lub usunięciem zasobów. Uszkodzone przesłanie może wyglądać jak problem z wydajnością.
6. Oddziel limity hosta od limitów skryptów
Monitoruj nasycenie CPU na rdzeń, obciążenie pamięci, opóźnienie przechowywania danych, utratę pakietów i lokalizację bazy danych. FiveM obciążenia mogą stanowić wąskie gardło dla jednego aktywnego rdzenia, podczas gdy całkowite użycie CPU nadal wygląda na niskie. Porównaj hosty z tym samym buildem i obciążeniem; sama pamięć RAM i reklamowane sloty nie dowodzą wydajności.
7. Wdróż i monitoruj
- Wykonaj kopię zapasową zasobu, konfiguracji i dotkniętych tabel bazy danych.
- Wdróż jedno zmierzone poprawkę na środowisko testowe.
- Powtórz scenariusz bazowy i porównaj te same metryki.
- Wdróż podczas kontrolowanego okna i obserwuj zacięcia, błędy i zgłoszenia graczy.
- Natychmiast wycofaj się, jeśli docelowa metryka lub przepływ rozgrywki ulegnie pogorszeniu.
Optymalizacja jest zakończona tylko wtedy, gdy zmierzony objaw ulegnie poprawie bez przenoszenia awarii gdzie indziej.