Identificeer prestatieproblemen

Het identificeren van prestatieproblemen betekent over het algemeen dat je je richt op een van de drie categorieën: frame rate (berekeningen), geheugen of laadtijd.

Roblox heeft een aantal tools voor het identificeren van prestatieproblemen, waarvan sommige beschikbaar zijn in de Roblox-client (en dus ook in Studio) en sommige alleen in Studio beschikbaar zijn. Terwijl je het gedrag van de client direct kunt observeren, moet je tools gebruiken om serverproblemen te diagnosticeren.

Diagnosetools

Serverberekeningen

De serverhartslag is beperkt tot 60 FPS voor alle games, dus lagere waarden kunnen wijzen op een prestatieprobleem. Om de serverhartslag te controleren:

• Met de Ontwikkelaarsconsole - Ga naar het tabblad Server Jobs, vouw de rij Heartbeat uit en controleer de waarde Steps Per Sec, die de hartslag van je game vertegenwoordigt.

• Met de MicroProfiler kun je de grafiek controleren om te zien of het frame langer dan 16,67 ms duurt.

  De MicroProfiler is bijzonder nuttig voor het identificeren van "spikes" in prestaties, waarbij sommige frames aanzienlijk langer duren om te verwerken dan andere.

Een ander symptoom van een verlaagde serverhartslag is verhoogde latentie (vaak ping genoemd). Hoe langer de server nodig heeft om zijn taken per frame te voltooien, hoe langer het duurt om netwerkgegevens die van clients zijn verzonden en ontvangen te verwerken. Om de gemiddelde ping voor alle spelers die verbonden zijn met een server te controleren, ga je naar het tabblad Server Stats in de Ontwikkelaarsconsole.

Als de serverhartslag laag blijft nadat je de prestaties hebt verbeterd, heeft je game mogelijk meer CPU nodig dan zijn servers standaard krijgen. Je kunt meer reserveren met Uitgebreide Diensten voor Berekeningen.

Clientberekeningen

De standaard client frame rate limiet is 60 FPS. Gebruikers kunnen echter hun frame rate limiet verhogen tot 240 FPS op Windows.

De frame rate verschilt sterk tussen apparaten. Een high-end pc kan bijvoorbeeld een rekenprobleem "brute-forcen" en alleen een onopvallende dip in de frame rate ervaren. Als je test op lagere-end apparaten, zijn de problemen vaak ernstiger en dus gemakkelijker op te merken.

Om de frame rate van je game te controleren:

• Druk in de client op ShiftF5 om de samenvatting van de debugstatistieken weer te geven.

• Ga vanuit het Venster ⟩ Prestatie menu van Studio naar Stats om de debugstatistieken in te schakelen.

  Prestatiestatistieken in Studio worden beïnvloed door de Studio-toepassing, dus je moet de frame rate op de client bekijken voor nauwkeurige cijfers.

• Met de MicroProfiler kun je de grafiek controleren om te zien of het frame langer dan 16,67 ms duurt.

Servergeheugen

Probeer het geheugengebruik van de server onder de 50% te houden. Het totale servergeheugen gebruikt de volgende formule:

6.25 GiB + (100 MiB * grootste_aantal_verbonden_spelers)

Bijvoorbeeld, een server met 30 verbonden spelers heeft ongeveer 9,18 GiB aan totaal geheugen. Servers winnen geheugen wanneer spelers verbinden, maar verliezen het niet wanneer spelers disconnecten. Als 10 spelers vertrekken, heeft de server nog steeds 9,18 GiB aan geheugen in plaats van te krimpen naar 8,2 GiB.

Wanneer servers worden afgesloten (bijvoorbeeld wanneer ze leeg zijn of als onderdeel van het updateproces), beginnen hun vervangingen met de basis hoeveelheid geheugen en beginnen op te schalen naarmate spelers verbinden.

Clientgeheugen

Er zijn verschillende manieren om het geheugengebruik voor een game te controleren:

1. Open de Ontwikkelaarsconsole en schakel over naar het tabblad Geheugen. Dit tabblad geeft een uitsplitsing van hoe geheugen wordt toegewezen. Gebruik de client in plaats van Studio om de meest nauwkeurige metingen te krijgen.
2. Schakel de weergave Prestatiestatistieken in vanuit het instellingenmenu in de client om een overlay te zien met het totale geheugengebruik van de client.

Hoog geheugengebruik is niet noodzakelijk indicatief voor een probleem, maar enkele aanwijzingen dat je mogelijk verder moet onderzoeken zijn:

• Een aanzienlijk percentage van clientcrashes dat wordt weergegeven in het Prestatie-dashboard, met name een plotselinge stijging die samenvalt met een update. Een aantal crashes is te verwachten, maar je moet onderzoeken of je crashpercentages boven de 2-3% stijgen.
• Een crash vindt plaats tijdens het testen op een apparaat dat je wilt dat je game ondersteunt.

Een aanzienlijk deel van het geheugengebruik van een game op de client komt van assets, zoals afbeeldingen, meshes en audiobestanden, die in het geheugen zijn geladen. Controleer in de Ontwikkelaarsconsole de volgende labels onder PlaceMemory:

• GraphicsMeshParts - Grafisch geheugen verbruikt door meshes.
• GraphicsTexture - Grafisch geheugen verbruikt door texturen.
• Sounds - Geheugen verbruikt door audiobestanden.

Laadtijden

Laadtijd, ook wel join-tijd genoemd, is de totale tijd vanaf het moment dat een speler op Play klikt tot het moment dat de wereld wordt weergegeven en ze kunnen beginnen met spelen. Nadat de client verbinding maakt met een server, gebeurt de join in de volgende volgorde:

1. ReplicatedFirst repliceert naar de client, en elke aangepaste laadscherm daarin verschijnt.
2. De rest van het datamodel repliceert, inclusief alles in ReplicatedStorage en Workspace. Als je instanties streaming inschakelt, repliceert alleen het gebied van de Workspace nabij het spawnpunt van de speler in deze fase.
3. De avatar van de speler laadt. De laadtijd eindigt wanneer het laadscherm verdwijnt en de wereld begint met renderen.

Weten welke stap traag is, helpt je om de optimalisaties met de grootste impact te kiezen. Voor veelvoorkomende oorzaken en oplossingen, zie Verbeter prestaties.

Er zijn geen ingebouwde tools voor het controleren van laadtijden, maar omdat ze geen milliseconde-niveau precisie vereisen, is een stopwatch meestal alles wat je nodig hebt om je huidige basislijn te begrijpen en te controleren of je een substantiële verbetering hebt aangebracht. Je kunt een clientscript in ReplicatedFirst gebruiken om een idee te krijgen van hoe je wijzigingen de laadtijden beïnvloeden, maar dit script biedt geen volledige, end-to-end meting. Het begint met timen nadat ReplicatedFirst repliceert en stopt wanneer de initiële replicatie is voltooid en DataModel.Loaded wordt geactiveerd, zodat het de tijd om verbinding te maken met een server of de avatar te laden niet omvat:

local startTime = os.clock()

game.Loaded:Connect(function()
  local loadTime = os.clock() - startTime
  local roundedLoadTime = math.round(loadTime * 10000) / 10000 -- vier decimalen
  print("Game geladen in " .. roundedLoadTime .. " seconden.")
  print("Aantal geladen instanties: " .. #workspace:GetDescendants())
end)

Voor aanvullende inzichten, schakel Print Join Size Breakdown in vanuit het Netwerk tabblad van Studio-instellingen om de top 20 instanties op grootte en een percentage uitsplitsing per instantie type af te drukken wanneer je de game in Studio start.

Als je laadtijd onverwacht hoog is in verhouding tot de schijnbare grootte van je game, inspecteer dan je plaats op niet-herkende of obfuscerende scripts. Sommige gratis modellen uit de Creator Store bevatten scripts die duizenden extra instanties genereren, wat de hoeveelheid gegevens die moet repliceren wanneer een speler zich aansluit, dramatisch verhoogt.

Meet de laadtijd voor en na elke optimalisatie of update, zodat je de impact ervan kunt bevestigen en regressies kunt opvangen. Een plotselinge stijging betekent vaak dat er recent inhoud is toegevoegd aan ReplicatedStorage of dat een wijziging in een asset de downloadgrootte heeft vergroot.

Ping

De twee belangrijkste metingen van ping (latentie) zijn netwerkping en gegevensping.

Netwerkping is de round-trip tijd gemeten vanaf het moment dat de client een netwerk datapakket verzendt tot het moment dat het de echo-antwoorden van de server ontvangt. Het is vergelijkbaar met wat zou worden gerapporteerd als time door de algemene ping-netwerkutility.

Netwerkping is zichtbaar in de Prestatiestatistieken balk. Het wordt voornamelijk beïnvloed door de lengte van het netwerkpad tussen de client en de server, en ligt buiten jouw controle. Je kunt echter ping en andere netwerkcondities simuleren met behulp van netwerksimulatie tijdens het playtesten in Studio.

Gegevensping is de round-trip tijd gemeten vanaf het moment dat de client gegevens betrouwbaar door het replicatiesysteem verzendt tot het moment dat het een echo-antwoord ontvangt van het replicatiesysteem van de server. Het omvat de tijd die wordt besteed in zowel de replicatiewachtrijen van de client als de server, samen met TCP-achtige hertransmissies van verloren of beschadigde pakketten.

Gegevensping is vergelijkbaar met het verzenden van een betrouwbare externe gebeurtenis van de client, deze ontvangen op de server, en vervolgens een betrouwbare externe gebeurtenis van de server naar de client verzenden als reactie. Omdat gegevensping ook de tijd omvat die op het netwerk tussen de client en server wordt besteed, is het groter dan of gelijk aan netwerkping.

De gemiddelde gegevensping voor alle spelers die verbonden zijn met een server is zichtbaar in het tabblad Server Stats van de Ontwikkelaarsconsole. Gegevensping voor een individuele client is zichtbaar met ShiftF3 om netwerk debugstatistieken weer te geven.

Gegevensping wordt beïnvloed door zowel het netwerkpad als door vertragingen in de replicatiewachtrijen. Wanneer de server replicatiegegevens sneller genereert dan het netwerk kan verzenden (of sneller dan de client kan verwerken), moet de data wachten in replicatiewachtrijen. Een verschil tussen gegevensping en netwerkping is normaal vanwege zowel netwerkhertransmissies als de manier waarop netwerkgegevens door de Roblox-app worden verwerkt. Als gegevensping echter aanzienlijk hoger is dan netwerkping, gebruik dan de MicroProfiler om het netwerkverkeer te bekijken. Voor optimalisatievoorstellen, zie netwerken en replicatie.