Identificare i problemi di prestazioni significa generalmente approfondire una delle tre categorie: frame rate (calcolo), memoria o tempo di caricamento.
Roblox dispone di diversi strumenti per identificare i problemi di prestazioni, alcuni dei quali sono disponibili nel client di Roblox (e quindi in Studio) e alcuni dei quali sono disponibili solo in Studio. Mentre puoi osservare direttamente il comportamento del client, devi utilizzare strumenti per diagnosticare i problemi del server.
Strumenti diagnostici
| Strumento | Descrizione | Posizione | Scorciatoia da tastiera | Ambiente |
|---|---|---|---|---|
| Console dello sviluppatore | Una console con messaggi di log in tempo reale, errori e informazioni dettagliate su memoria, rete e prestazioni degli script. È utile per visualizzare il consumo di memoria, le statistiche chiave sulla salute del server, le statistiche sulle prestazioni degli script e per avviare il MicroProfiler del client o del server. | Studio In-Game | F9 | Studio Testing Live Sessions |
| MicroProfiler | Uno strumento di debug che analizza quanto tempo computazionale viene speso per i compiti in ogni frame. Può generare dump per l'analisi mostrando una suddivisione precisa dei singoli frame, rendendolo utile per identificare il compito specifico che causa problemi di prestazioni. Puoi eseguire il profiler sia sul client che sul server, a seconda di quale lato ha un problema. | Studio In-Game | CtrlAltF6 (⌘⌥F6) | Studio Testing Live Sessions |
| Analisi della scena | Fornisce informazioni comparative a colpo d'occhio sulle risorse utilizzate dalle scene del client e del server e quali istanze sono responsabili di quel consumo di risorse. | Studio | N/A | Studio Testing |
| Statistiche sulle prestazioni | Una barra degli strumenti con statistiche di base sulle prestazioni, inclusi consumo di memoria, CPU, GPU, dati di rete inviati e ricevuti e tempo di ping. | In-Game | CtrlAltF7 (⌘⌥F7) | Studio Testing Live Sessions |
| Statistiche di debug | Overlay con informazioni dettagliate su grafica, fisica, traffico di rete e FPS. | Studio In-Game | ShiftCtrlF1 (Shift⌘F1), ShiftCtrlF2 (Shift⌘F2), ShiftCtrlF3 (Shift⌘F3), ShiftCtrlF4 (Shift⌘F4), ShiftCtrlF5 (Shift⌘F5) | Studio Testing Live Sessions |
| Simulazione di rete | Proprietà che simulano condizioni di rete del mondo reale come latenza, jitter e perdita di pacchetti per testare le connessioni. | Studio | AltS(⌥S) | Studio Testing |
| Dashboard delle prestazioni | Un dashboard con grafici aggregati per l'uso della memoria del client e del server, frame rate del client, battito del server e tassi di crash in tempo reale. È utile per analizzare i modelli di prestazioni nel tempo. Vedi monitoraggio delle prestazioni. | Creator Dashboard | N/A | Live Sessions |
Calcolo del server
Il battito del server è limitato a 60 FPS per tutti i giochi, quindi valori più bassi potrebbero indicare un problema di prestazioni. Per controllare il battito del server:
Con la Console dello sviluppatore - Nella scheda Server Jobs, espandi la riga Heartbeat e controlla il valore Steps Per Sec, che rappresenta il battito del tuo gioco.
Con il MicroProfiler, puoi controllare il grafico per vedere se il frame impiega più di 16,67 ms.
Un altro sintomo di un battito del server degradato è l'aumento della latenza (comunemente noto come ping). Più a lungo il server impiega a completare i suoi compiti in ogni frame, più a lungo impiega a elaborare i dati di rete inviati e ricevuti dai client. Per controllare il ping medio per tutti i giocatori connessi a un server, vai alla scheda Server Stats nella Console dello sviluppatore.
Se il battito del server rimane basso dopo aver migliorato le prestazioni, il tuo gioco potrebbe aver bisogno di più CPU di quella che i suoi server ottengono per impostazione predefinita. Puoi riservarne di più con Servizi Estesi per il Calcolo.
Calcolo del client
Il limite di frame rate predefinito del client è di 60 FPS. Tuttavia, gli utenti possono aumentare il loro limite di frame rate fino a 240 FPS su Windows.
Il frame rate varia notevolmente tra i dispositivi. Ad esempio, un PC di fascia alta potrebbe essere in grado di "forzare" un problema computazionale e sperimentare solo un calo di frame rate impercettibile. Se testi su dispositivi di fascia bassa, i problemi tendono a essere più gravi e quindi più facili da notare.
Per controllare il frame rate del tuo gioco:
Nel client, premi ShiftF5 per mostrare il riepilogo delle statistiche di debug.
Dal menu Finestra ⟩ Prestazioni di Studio, attiva Statistiche per abilitare le statistiche di debug.
Con il MicroProfiler, puoi controllare il grafico per vedere se il frame impiega più di 16,67 ms.
Memoria del server
Cerca di mantenere l'uso della memoria del server al di sotto del 50%. La memoria totale del server utilizza la seguente formula:
6.25 GiB + (100 MiB * numero_massimo_di_giocatori_connessi)
Ad esempio, un server con 30 giocatori connessi ha circa 9.18 GiB di memoria totale. I server guadagnano memoria quando i giocatori si connettono, ma non la perdono quando i giocatori si disconnettono. Se 10 giocatori escono, il server ha ancora 9.18 GiB di memoria anziché ridursi a 8.2 GiB.
Quando i server si spengono (ad esempio, quando sono vuoti o come parte del processo di aggiornamento), le loro sostituzioni iniziano con la quantità base di memoria e iniziano a scalare man mano che i giocatori si connettono.
Memoria del client
Ci sono diversi modi per controllare l'uso della memoria per un gioco:
- Apri la Console dello sviluppatore e passa alla scheda Memoria. Questa scheda fornisce una suddivisione di come viene allocata la memoria. Usa il client piuttosto che Studio per ottenere le letture più accurate.
- Abilita la visualizzazione Statistiche sulle prestazioni dal menu delle impostazioni nel client per vedere un overlay con l'uso totale della memoria del client.
Un alto utilizzo della memoria non è necessariamente indicativo di un problema, ma alcune indicazioni che potresti dover indagare ulteriormente sono:
- Una percentuale significativa di crash del client mostrata nel Dashboard delle prestazioni, in particolare un improvviso aumento che coincide con un aggiornamento. Alcuni crash sono attesi, ma dovresti indagare se i tuoi tassi di crash aumentano oltre il 2-3%.
- Un crash si verifica durante il test su un dispositivo che desideri che il tuo gioco supporti.
Una parte significativa del consumo di memoria di un gioco sul client proviene da asset, come immagini, mesh e file audio, caricati in memoria. Nella Console dello sviluppatore, controlla le seguenti etichette sotto PlaceMemory:
- GraphicsMeshParts - Memoria grafica consumata da mesh.
- GraphicsTexture - Memoria grafica consumata da texture.
- Sounds - Memoria consumata da file audio.
Tempi di caricamento
Il tempo di caricamento, noto anche come tempo di accesso, è il tempo totale da quando un giocatore fa clic su Gioca a quando il mondo viene renderizzato e possono iniziare a giocare. Dopo che il client si connette a un server, l'accesso avviene nel seguente ordine:
- ReplicatedFirst si replica nel client e qualsiasi schermata di caricamento personalizzata al suo interno appare.
- Il resto del modello di dati si replica, inclusi tutto in ReplicatedStorage e Workspace. Se abiliti lo streaming delle istanze, solo l'area di Workspace vicino al punto di spawn del giocatore si replica in questa fase.
- L'avatar del giocatore si carica. Il tempo di caricamento termina quando la schermata di caricamento scompare e il mondo inizia a essere renderizzato.
Sapere quale passaggio è lento ti aiuta a scegliere le ottimizzazioni con il maggiore impatto. Per cause e soluzioni comuni, vedi Migliora le prestazioni.
Non ci sono strumenti integrati per controllare i tempi di caricamento, ma poiché non richiedono precisione a livello di millisecondo, un cronometro è di solito tutto ciò di cui hai bisogno per comprendere la tua attuale base e controllare se hai apportato un miglioramento sostanziale. Puoi utilizzare uno script client in ReplicatedFirst per avere un'idea di come le tue modifiche influenzano i tempi di caricamento, ma questo script non fornisce una misurazione completa e end-to-end. Inizia a cronometrare dopo che ReplicatedFirst si replica e si ferma quando la replicazione iniziale termina e si attiva DataModel.Loaded, quindi non include il tempo per connettersi a un server o caricare l'avatar:
local startTime = os.clock()
game.Loaded:Connect(function()
local loadTime = os.clock() - startTime
local roundedLoadTime = math.round(loadTime * 10000) / 10000 -- quattro decimali
print("Gioco caricato in " .. roundedLoadTime .. " secondi.")
print("Numero di istanze caricate: " .. #workspace:GetDescendants())
end)Per ulteriori informazioni, abilita Stampa della suddivisione della dimensione di accesso dalla scheda Rete delle Impostazioni di Studio per stampare le prime 20 istanze per dimensione e una suddivisione percentuale per tipo di istanza quando avvii il gioco in Studio.
Se il tuo tempo di caricamento è inaspettatamente alto rispetto alla dimensione apparente del tuo gioco, ispeziona il tuo luogo per script non riconosciuti o offuscati. Alcuni modelli gratuiti del Creator Store contengono script che generano migliaia di istanze extra, il che aumenta drammaticamente la quantità di dati che devono replicarsi quando un giocatore si unisce.
Misura il tempo di caricamento prima e dopo ogni ottimizzazione o aggiornamento in modo da poter confermare il suo impatto e rilevare regressioni. Un aumento improvviso spesso significa che è stato recentemente aggiunto contenuto a ReplicatedStorage o che una modifica dell'asset ha aumentato la dimensione del download.
Ping
Le due misurazioni principali del ping (latenza) sono ping di rete e ping di dati.
Il ping di rete è il tempo di andata e ritorno misurato da quando il client invia un pacchetto di dati di rete a quando riceve la risposta di eco del server. È simile a ciò che verrebbe riportato come time dall'utilità di rete ping di uso generale.
Il ping di rete è visibile nella barra delle Statistiche sulle prestazioni. È principalmente influenzato dalla lunghezza del percorso di rete tra il client e il server ed è al di fuori del tuo controllo. Tuttavia, puoi simulare il ping e altre condizioni di rete utilizzando la simulazione di rete durante il playtesting in Studio.
Il ping di dati è il tempo di andata e ritorno misurato da quando il client invia dati in modo affidabile attraverso il sistema di replicazione a quando riceve una risposta di eco dal sistema di replicazione del server. Include il tempo trascorso sia nelle code di replicazione del client che del server, insieme a ritrasmissioni simili a TCP di pacchetti persi o corrotti.
Il ping di dati è simile all'invio di un evento remoto affidabile dal client, ricevendolo sul server e poi inviando un evento remoto affidabile dal server al client in risposta. Poiché il ping di dati include anche il tempo trascorso sulla rete tra il client e il server, è maggiore o uguale al ping di rete.
Il ping di dati medio per tutti i giocatori connessi a un server è visibile nella scheda Server Stats della Console dello sviluppatore. Il ping di dati per un singolo client è visibile utilizzando ShiftF3 per visualizzare le statistiche di debug della rete.
Il ping di dati è influenzato sia dal percorso di rete che dai ritardi di coda di replicazione. Quando il server genera dati di replicazione più velocemente di quanto la rete possa inviarli (o più velocemente di quanto il client possa elaborarli), i dati devono attendere nelle code di replicazione. Alcune differenze tra il ping di dati e il ping di rete sono normali a causa sia delle ritrasmissioni di rete che del modo in cui i dati di rete vengono elaborati dall'app Roblox. Tuttavia, se il ping di dati è significativamente più alto del ping di rete, utilizza il MicroProfiler per visualizzare il traffico di rete. Per suggerimenti di ottimizzazione, vedi networking e replicazione.