Identifier les problèmes de performance signifie généralement se concentrer sur l'une de 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, certains d'entre eux étant disponibles dans le client Roblox (et donc dans Studio), et certains n'étant disponibles que dans Studio. Alors que vous pouvez observer directement le comportement du client, vous devez utiliser des outils pour diagnostiquer les problèmes du serveur.
Outils de diagnostic
| Outil | Description | Emplacement | Raccourci clavier | Environnement |
|---|---|---|---|---|
| Console du développeur | Une console avec des messages de log 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 de santé clés du serveur, les statistiques de performance des scripts et pour lancer le MicroProfiler du client ou du serveur. | Studio En jeu | F9 | Tests dans Studio Sessions en direct |
| MicroProfiler | Un outil de débogage qui décompose le temps de calcul passé sur des tâches à chaque trame. Il peut générer des dumps pour analyse montrant une répartition précise des trames individuelles, ce qui est 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 dans Studio Sessions en direct |
| Analyse de scène | Fournit des informations comparatives instantanées sur les ressources utilisées par vos scènes client et serveur et lesquelles des instances sont responsables de cette utilisation des ressources. | Studio | N/A | Tests dans 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 dans Studio Sessions en direct |
| Statistiques de débogage | Couches d'informations détaillées autour des graphiques, de la physique, du trafic réseau et des FPS. | Studio En jeu | ShiftCtrlF1 (Shift⌘F1), ShiftCtrlF2 (Shift⌘F2), ShiftCtrlF3 (Shift⌘F3), ShiftCtrlF4 (Shift⌘F4), ShiftCtrlF5 (Shift⌘F5) | Tests dans 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 dans Studio |
| Tableau de performance | Un tableau de bord avec des graphiques agrégés pour l'utilisation de mémoire client et serveur, le taux de trame du client, le battement 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 Créateur | N/A | Sessions en direct |
Calcul serveur
Le battement du serveur est limité à 60 FPS pour tous les jeux, donc des valeurs plus basses pourraient indiquer un problème de performance. Pour vérifier le battement du serveur :
Avec la Console du développeur - Dans l'onglet Travaux du serveur, développez la ligne Battement et vérifiez la valeur Étapes par sec, qui représente le battement de votre jeu.
Avec le MicroProfiler, vous pouvez vérifier le graphique pour voir si la trame prend plus de 16,67 ms.
Un autre symptôme d'un battement de 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 à l'onglet Statistiques du serveur dans la Console du développeur.
Calcul client
La limite de fréquence d'images par défaut du client est de 60 FPS. Cependant, les utilisateurs peuvent augmenter leur limite de fréquence d'images jusqu'à 240 FPS sur Windows.
Le taux de trame diffère considérablement 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 perceptible du taux de trame. Si vous testez sur des appareils d'entrée de gamme, les problèmes ont tendance à ê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.
À partir du menu Fenêtre ⟩ Performance de Studio, activez Statistiques pour activer les statistiques de débogage.
Avec le MicroProfiler, vous pouvez vérifier le graphique pour voir si la trame prend plus de 16,67 ms.
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)
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 plutôt que de réduire à 8,2 GiB.
Lorsque les serveurs s'éteignent (par exemple, lorsqu'ils sont vides ou dans le cadre du processus de mise à jour), leurs remplaçants commencent avec la quantité de mémoire de base et commencent à augmenter à mesure que les 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 Mémoire. Cet onglet fournit une répartition de la façon dont la mémoire est allouée. Utilisez le client plutôt que Studio pour obtenir les mesures les plus précises.
- Activez la vue Statistiques de performance à partir du menu des paramètres dans le client pour voir un overlay avec l'utilisation totale de la mémoire client.
Une utilisation élevée de la mémoire n'indique pas nécessairement un problème, mais certaines indications selon lesquelles vous pourriez devoir enquêter davantage incluent :
- Un pourcentage significatif de plantages clients apparaissant dans le Tableau de performance, en particulier une augmentation soudaine qui coïncide avec une mise à jour. Un certain nombre de plantages est attendu, mais vous devriez enquêter si vos taux de plantage augmentent au-dessus de 2-3 %.
- Un plantage se produit lors des tests sur un appareil que vous souhaitez que votre jeu prenne en charge.
Une part importante 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
Il n'y a 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 base 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 :
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 Imprimer la répartition de la taille de jointure à partir de l'onglet Réseau des Paramètres de Studio pour imprimer les 20 instances les plus importantes par taille et une répartition par pourcentage par type d'instance lorsque vous commencez le jeu dans Studio.
Ping
Les deux mesures principales de ping (latence) sont le ping réseau et le ping de données.
Le ping réseau est le temps de boucle 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é en tant que time par l'utilitaire de ping réseau à usage général.
Le ping réseau est visible dans la barre de Statistiques de performance. Il est principalement affecté par la longueur du chemin réseau entre le client et le serveur, et est hors 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 dans Studio.
Le ping de données est le temps de boucle 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 comprend le temps passé dans les files d'attente de réplication du client et du serveur, ainsi que les retransmissions TCP-like des paquets perdus ou corrompus.
Le ping de données est similaire à l'envoi d'un événement distant fiable depuis le client, la réception de celui-ci sur le serveur, puis l'envoi d'un événement distant fiable du serveur au 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 Statistiques du serveur 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. Lorsqu'un 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 des files d'attente de réplication. Certaines différences entre le ping de données et le ping réseau sont normales 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éseautage et réplication.