Identifier les problèmes de performance | Documentation

Identifier les problèmes de performance signifie généralement se concentrer sur l'une des trois catégories : le taux de trame (calcul), la mémoire ou le temps de chargement.

Roblox dispose de plusieurs outils pour identifier les problèmes de performance, dont certains sont disponibles dans le client Roblox (et donc dans Studio) et d'autres qui ne sont disponibles que dans Studio. Alors que vous pouvez observer le comportement du client directement, vous devez utiliser des outils pour diagnostiquer les problèmes de serveur.

Outils de diagnostic

Outil	Description	Emplacement	Raccourci clavier	Environnement
Console du développeur	Une console avec des messages de journal en temps réel, des erreurs et des informations détaillées sur la mémoire, le réseau et la performance des scripts. Elle est utile pour visualiser la consommation de mémoire, les statistiques clés de santé du serveur, les statistiques de performance des scripts et pour lancer le MicroProfiler du client ou du serveur.	Studio En jeu	F9	Tests en studio Sessions en direct
MicroProfiler	Un outil de débogage qui décompose le temps de calcul passé sur les tâches à chaque trame. Il peut générer des dumps pour analyse montrant une répartition précise des trames individuelles, ce qui le rend utile pour identifier la tâche spécifique causant des problèmes de performance. Vous pouvez exécuter le profiler soit sur le client, soit sur le serveur, selon le côté qui a un problème.	Studio En jeu	CtrlAltF6 (⌘⌥F6)	Tests en studio Sessions en direct
Analyse de scène	Fournit des informations comparatives en un coup d'œil sur les ressources utilisées par vos scènes client et serveur et sur les instances responsables de cette utilisation des ressources.	Studio	N/A	Tests en studio
Statistiques de performance	Une barre d'outils avec des statistiques de performance de base, y compris la consommation de mémoire, le CPU, le GPU, les données réseau envoyées et reçues, et le temps de ping.	En jeu	CtrlAltF7 (⌘⌥F7)	Tests en studio Sessions en direct
Statistiques de débogage	Superpositions avec des informations détaillées sur les graphiques, la physique, le trafic réseau et les FPS.	Studio En jeu	ShiftCtrlF1 (Shift⌘F1), ShiftCtrlF2 (Shift⌘F2), ShiftCtrlF3 (Shift⌘F3), ShiftCtrlF4 (Shift⌘F4), ShiftCtrlF5 (Shift⌘F5)	Tests en studio Sessions en direct
Simulation de réseau	Propriétés qui simulent des conditions réseau réelles comme la latence, le jitter et la perte de paquets pour tester les connexions.	Studio	AltS(⌥S)	Tests en studio
Tableau de performance	Un tableau de bord avec des graphiques agrégés pour l'utilisation de la mémoire client et serveur, le taux de trame client, le battement de cœur du serveur et les taux de crash en temps réel. Il est utile pour analyser les modèles de performance au fil du temps. Voir surveillance de la performance.	Tableau de bord du créateur	N/A	Sessions en direct

Calcul serveur

Le battement de cœur du serveur est limité à 60 FPS pour tous les jeux, donc des valeurs plus basses peuvent indiquer un problème de performance. Pour vérifier le battement de cœur du serveur :

Avec la Console du développeur - Dans l'onglet Server Jobs, développez la ligne Heartbeat et vérifiez la valeur Steps Per Sec, qui représente le battement de cœur de votre jeu.
Avec le MicroProfiler, vous pouvez vérifier le graphique pour voir si la trame prend plus de 16,67 ms.

Le MicroProfiler est particulièrement utile pour identifier les "pics" de performance, où certaines trames prennent beaucoup plus de temps que d'autres à traiter.

Un autre symptôme d'un battement de cœur du serveur dégradé est une latence accrue (communément appelée ping). Plus le serveur met de temps à terminer le calcul de ses tâches à chaque trame, plus il met de temps à traiter les données réseau envoyées et reçues des clients. Pour vérifier le ping moyen de tous les joueurs connectés à un serveur, allez dans l'onglet Server Stats de la Console du développeur.

Si le battement de cœur du serveur reste bas après que vous ayez amélioré la performance, votre jeu pourrait nécessiter plus de CPU que ce que ses serveurs obtiennent par défaut. Vous pouvez en réserver davantage avec Services étendus pour le calcul.

Calcul client

La limite de taux de trame par défaut du client est de 60 FPS. Cependant, les utilisateurs peuvent augmenter leur limite de taux de trame jusqu'à 240 FPS sur Windows.

Le taux de trame varie énormément entre les appareils. Par exemple, un PC haut de gamme pourrait être capable de "forcer" un problème de calcul et ne subir qu'une baisse de taux de trame imperceptible. Si vous testez sur des appareils moins puissants, les problèmes tendent à être plus graves et donc plus faciles à remarquer.

Pour vérifier le taux de trame de votre jeu :

Dans le client, appuyez sur ShiftF5 pour afficher le résumé des statistiques de débogage.
Dans le menu Window ⟩ Performance de Studio, activez Stats pour activer les statistiques de débogage.

Les statistiques de performance dans Studio sont faussées par l'application Studio, donc vous devriez visualiser le taux de trame sur le client pour obtenir des chiffres précis.
Avec le MicroProfiler, vous pouvez vérifier le graphique pour voir si la trame prend plus de 16,67 ms.

Lors de l'évaluation du taux de trame, il peut être utile de régler la qualité graphique à sa valeur maximale pour éliminer l'effet du gestionnaire de taux de trame. Dans le client, ouvrez le menu, cliquez sur Settings, changez Graphics Mode en manuel, et augmentez la qualité graphique.

Mémoire serveur

Essayez de garder l'utilisation de la mémoire du serveur en dessous de 50 %. La mémoire totale du serveur utilise la formule suivante :

6,25 GiB + (100 MiB * plus_grande_nombre_de_joueurs_connectés)

Ces chiffres utilisent des puissances de 2, donc 1 GiB fait référence à 2^30 octets et 1 MiB à 2^20 octets.

Par exemple, un serveur avec 30 joueurs connectés a environ 9,18 GiB de mémoire totale. Les serveurs gagnent de la mémoire lorsque des joueurs se connectent, mais ne la perdent pas lorsque des joueurs se déconnectent. Si 10 joueurs partent, le serveur a toujours 9,18 GiB de mémoire au lieu de diminuer à 8,2 GiB.

Lorsque les serveurs s'éteignent (par exemple, lorsqu'ils sont vides ou dans le cadre du processus de mise à jour), leurs remplacements commencent avec la quantité de mémoire de base et commencent à augmenter à mesure que des joueurs se connectent.

Mémoire client

Il existe plusieurs façons de vérifier l'utilisation de la mémoire pour un jeu :

Ouvrez la Console du développeur et passez à l'onglet Memory. Cet onglet donne une répartition de la façon dont la mémoire est allouée. Utilisez le client plutôt que Studio pour obtenir les lectures les plus précises.
Activez la vue Performance Stats depuis le menu des paramètres dans le client pour voir une superposition avec l'utilisation totale de la mémoire client.

Une utilisation élevée de la mémoire n'est pas nécessairement indicative d'un problème, mais certaines indications que vous pourriez avoir besoin d'enquêter davantage sont :

Un pourcentage significatif de crashs clients affichés dans le Tableau de performance, en particulier une augmentation soudaine qui coïncide avec une mise à jour. Un certain nombre de crashs sont attendus, mais vous devriez enquêter si vos taux de crash augmentent au-dessus de 2-3 %.
Un crash se produit lors des tests sur un appareil que vous souhaitez que votre jeu prenne en charge.

Une part significative de la consommation de mémoire d'un jeu sur le client provient des actifs, tels que des images, des maillages et des fichiers audio, chargés en mémoire. Dans la Console du développeur, vérifiez les étiquettes suivantes sous PlaceMemory :

GraphicsMeshParts - Mémoire graphique consommée par les maillages.
GraphicsTexture - Mémoire graphique consommée par les textures.
Sounds - Mémoire consommée par les fichiers audio.

Temps de chargement

Le temps de chargement, également appelé temps de connexion, est le temps total écoulé depuis qu'un joueur clique sur Play jusqu'à ce que le monde soit rendu et qu'il puisse commencer à jouer. Après que le client se soit connecté à un serveur, la connexion se fait dans l'ordre suivant :

ReplicatedFirst se réplique au client, et tout écran de chargement personnalisé à l'intérieur apparaît.
Le reste du modèle de données se réplique, y compris tout ce qui se trouve dans ReplicatedStorage et Workspace. Si vous activez le streaming d'instances, seule la zone de Workspace près du point de spawn du joueur se réplique à ce stade.
L'avatar du joueur se charge. Le temps de chargement se termine lorsque l'écran de chargement disparaît et que le monde commence à se rendre.

Savoir quelle étape est lente vous aide à choisir les optimisations ayant le plus grand impact. Pour les causes et les solutions courantes, voir Améliorer la performance.

Il n'existe pas d'outils intégrés pour vérifier les temps de chargement, mais comme ils ne nécessitent pas de précision au niveau de la milliseconde, un chronomètre est généralement tout ce dont vous avez besoin pour comprendre votre référence actuelle et vérifier si vous avez apporté une amélioration substantielle. Vous pouvez utiliser un script client dans ReplicatedFirst pour avoir une idée de la façon dont vos modifications impactent les temps de chargement, mais ce script ne fournit pas une mesure complète de bout en bout. Il commence à chronométrer après que ReplicatedFirst se soit répliqué et s'arrête lorsque la réplication initiale est terminée et que DataModel.Loaded est déclenché, donc il n'inclut pas le temps nécessaire pour se connecter à un serveur ou charger l'avatar :

local startTime = os.clock()

game.Loaded:Connect(function()
  local loadTime = os.clock() - startTime
  local roundedLoadTime = math.round(loadTime * 10000) / 10000 -- quatre décimales
  print("Jeu chargé en " .. roundedLoadTime .. " secondes.")
  print("Nombre d'instances chargées : " .. #workspace:GetDescendants())
end)

Pour des informations supplémentaires, activez Print Join Size Breakdown depuis l'onglet Network des Paramètres de Studio pour imprimer les 20 instances les plus importantes par taille et une répartition en pourcentage par type d'instance lorsque vous démarrez le jeu dans Studio.

Si votre temps de chargement est anormalement élevé par rapport à la taille apparente de votre jeu, inspectez votre lieu pour des scripts non reconnus ou obfusqués. Certains modèles gratuits du Creator Store contiennent des scripts qui génèrent des milliers d'instances supplémentaires, ce qui augmente considérablement la quantité de données à répliquer lorsque un joueur se connecte.

Mesurez le temps de chargement avant et après chaque optimisation ou mise à jour afin de pouvoir confirmer son impact et détecter les régressions. Une augmentation soudaine signifie souvent que du contenu a été récemment ajouté à ReplicatedStorage ou qu'un changement d'actif a augmenté la taille de téléchargement.

Ping

Les deux principales mesures de ping (latence) sont le ping réseau et le ping de données.

Le ping réseau est le temps de trajet aller-retour mesuré depuis que le client envoie un paquet de données réseau jusqu'à ce qu'il reçoive la réponse d'écho du serveur. Il est similaire à ce qui serait rapporté comme time par l'utilitaire de réseau ping à usage général.

Le ping réseau est visible dans la barre des Statistiques de performance. Il est principalement affecté par la longueur du chemin réseau entre le client et le serveur, et est en dehors de votre contrôle. Cependant, vous pouvez simuler le ping et d'autres conditions réseau en utilisant la simulation de réseau lors des tests en studio.

Le ping de données est le temps de trajet aller-retour mesuré depuis que le client envoie des données de manière fiable à travers le système de réplication jusqu'à ce qu'il reçoive une réponse d'écho du système de réplication du serveur. Il inclut le temps passé dans les files d'attente de réplication du client et du serveur, ainsi que les retransmissions de type TCP des paquets perdus ou corrompus.

Le ping de données est similaire à l'envoi d'un événement distant fiable depuis le client, à sa réception sur le serveur, puis à l'envoi d'un événement distant fiable depuis le serveur vers le client en réponse. Comme le ping de données inclut également le temps passé sur le réseau entre le client et le serveur, il est supérieur ou égal au ping réseau.

Le ping de données moyen pour tous les joueurs connectés à un serveur est visible dans l'onglet Server Stats de la Console du développeur. Le ping de données pour un client individuel est visible en utilisant ShiftF3 pour afficher les statistiques de débogage réseau.

Le ping de données est affecté à la fois par le chemin réseau et par les délais de mise en file d'attente de réplication. Lorsque le serveur génère des données de réplication plus rapidement que le réseau ne peut les envoyer (ou plus rapidement que le client ne peut les traiter), les données doivent attendre dans les files d'attente de réplication. Une certaine différence entre le ping de données et le ping réseau est normale en raison des retransmissions réseau et de la façon dont les données réseau sont traitées par l'application Roblox. Cependant, si le ping de données est significativement plus élevé que le ping réseau, utilisez le MicroProfiler pour visualiser le trafic réseau. Pour des suggestions d'optimisation, voir réseau et réplication.