Performance Dashboard

*Ce contenu sera bientôt disponible dans la langue que vous avez sélectionnée.

The Performance dashboard provides up-to-the-minute client and server metrics for your experience. Monitor this page before and after updating your experience to identify performance issues early.

An overview of the performance dashboard.

Accessing the Dashboard

To access the Performance page, you must either be the experience owner or have analytics group permissions.

  1. Navigate to the Creations page on the Creator Hub.
  2. Under the Creator Hub dropdown, select your account or the group that owns the experience.
  3. Select the experience.
  4. In the Monitoring dropdown, select Performance.

Using the Dashboard

The dashboard begins with the current number of users, the number of servers they are spread across, and a device breakdown. For the dashboard to show client and server charts like the ones below, your experience must have at least 100 daily active users (DAU).

The dashboard contains two tabs, Client and Server, along with menus to adjust date range and time interval. You can also use the Place menu to examine individual places rather than the entire experience.

A marked up view of the performance dashboard UI.

The Filter By menu lets you swap between averages or percentile values.

A view of the filters menu.

When reviewing charts or filtering:

  • P90 refers to the number of values that fall within the 90th percentile. If P90 server heartbeat is 59, then 90% of servers are running at or below 59 FPS.
  • Similarly, P10 refers to the 10th percentile. If P10 server heartbeat is 40, then 10% of servers are running at or below 40 FPS.
  • P50 is the median. Half of all values fall above it, half below.

Client Charts

The Client tab includes the following charts, all of which are broken down by platform or operating system:

ChartDescription
Concurrent usersLine graph showing the number of users in your experience.
Session timeDuration that users spend in your experience.
Client frame rateLine graph showing client frames per second. Persistent low frame rates or large drops may signal issues. For information on investigating client frame rate, see Client Compute.
Client crash rateLine graph showing client crash rate by device type. Spikes in crash rate, particularly following an update to the experience, often indicate an issue.
Client memory usageLine graph showing client memory usage by device type. Continual increases can indicate a memory leak. See Memory.
Client memory usage percentageLine graph showing percentage of available device memory the client is using. For example, if the Android line approaches 100%, the majority of Android devices running your experience are at risk of running out of memory and crashing.

Server Charts

The Server tab includes the following charts:

ChartDescription
Server CPU timeStacked area chart showing milliseconds (ms) of processing time per frame. Values over 16.67 ms are highly undesirable; they can cause server frame rates to drop below 60. See Server Compute
Server frame rateLine graph showing server frame rate in FPS. Ideally, this value is always 60. Server frame rate is capped at 60, and drops can reduce client frame rate and increase latency. See Script Computation.
Server memory usageStacked area chart showing server memory usage in MB. Try to keep this value below 50% of the total server memory. However, the chart doesn't show the total server memory, so another good guideline is to stay below 3 GB. If this number stays high or continually increases over time, investigate ways to improve memory usage.
Server memory by ageStacked area chart showing server memory usage by server age. If memory usage increases significantly over the lifespan of the server, investigate possible memory leaks in the categories with the most growth, particularly scripts, physics, and rendering.
Cores used per serverLine graph showing server CPU core count usage. Low core count usage combined with high server CPU time is an indicator that you should investigate Multithreading.
Compute efficiencyLine graph showing the efficiency of your experience compared to the Roblox average. Values above 100% indicate higher efficiency than the baseline. Contributing factors include maximum number of players per server (higher is more efficient) and server CPU time per frame (lower is more efficient). Higher compute efficiency means lower environmental impact, but this metric is not indicative of a good or bad player experience.

The server CPU and memory charts default to the Overall view, but have dropdown menus for individual process groups, such as physics, rendering, and scripts. The sum of these categories is not comprehensive; the server performs a small—typically insignificant—amount of additional work per frame that isn't included in any category. As such, the overall millisecond and MB values are slightly lower than reality, but close enough to give you a clear understanding of server performance.

If a category is higher than usual or appears to be taking up a disproportionate amount of time, use the dropdown menu to drill down on the group and identify processes that could be causing issues.

The server CPU time chart showing the physics dropdown.
  • CPU categories and tasks map to the ones in the MicroProfiler, so you can take server dumps, select Timers mode, and then use the Groups menu to filter by the problematic process group.

    For example, if you spot a potential problem with the assemble process under the Physics group, you can find it under the same name in the MicroProfiler:

    The MicroProfiler showing the assemble process within the Physics group.
  • Memory tags map to the ones in Enum.DeveloperMemoryTag, with the notable exception of CoreMemory:Total, which is equivalent to Enum.DeveloperMemoryTag.Internal. You can use the Developer Console to check tags for excessive usage. This image shows how you might use the Developer Console to investigate an issue with PlaceMemory:GraphicsTexture that you see in the dashboard:

    The Developer Console showing the server memory view.

Troubleshooting

If you spot a potential problem, use the following steps to remediate and fix it:

  1. Check your recent updates and consider rolling them back if the impact to metrics is severe.

  2. See the Identifying Performance Issues and Improving Performance for information on troubleshooting problems with server compute, client compute, and memory usage.

  3. Use built-in testing tools to further drill down on problems:

    • Developer Console for viewing error and log messages and detailed information on memory and networking.
    • Script Profiler for identifying scripts that take up the most resources.
    • The MicroProfiler for viewing unoptimized portions of your experience visually.
  4. Gather user feedback from your community.