Identifying Performance Issues | Documentation

Identifying performance issues generally means drilling down on one of three categories: frame rate (compute), memory, or load time.

Roblox has a number of tools for identifying performance issues, some of which are available in the Roblox client (and therefore Studio) and some of which are only available in Studio. Whereas you can observe client behavior directly, you must use tools to diagnose server issues.

Diagnostic Tools

Tool	Description	Location	Keyboard shortcut	Environment
Developer Console	A console with real-time log messages, errors, and detailed information on memory, networking, and script performance. It's useful for viewing memory consumption, key server health stats, script performance stats, and to launch the client or server MicroProfiler.	Studio	F9	Live sessions, Studio testing
MicroProfiler	A debugging tool that breaks down how much computational time is spent on tasks each frame. It can generate dumps for analysis showing a precise breakdown of individual frames, making it helpful for identifying the specific task causing performance issues. You can run the profiler on either the client or the server, depending on which side has an issue.	In-experience	CtrlAltF6 (⌘⌥F6)	Live sessions, Studio testing
Performance Stats Bar	A toolbar with basic performance statistics, including memory consumption, CPU, GPU, network data sent and received, and ping time.	In-experience	CtrlAltF7 (⌘⌥F7)	Live sessions, Studio testing
Debug Stats	Overlays with detailed information around graphics, physics, network traffic, and FPS.	In-experience	ShiftF1, ShiftF2, ShiftF3, ShiftF4, ShiftF5	Live sessions, Studio testing
Performance Dashboard	A dashboard with aggregate charts for client and server memory usage, client frame rate, server heartbeat, and crash rates in real-time. It's helpful for analyzing performance patterns over time. See Monitoring Performance.	Creator Dashboard	N/A	Live sessions

Server Compute

Server heartbeat is capped at 60 FPS for all experiences, so lower values might indicate a performance issue. To check server heartbeat:

With the Developer Console - In the Server Jobs tab, expand the Heartbeat row and check the Steps Per Sec value, which represents the heartbeat of your experience.
With the server MicroProfiler - Look at the length of each frame to see if some are taking longer than 16.67 ms.

The MicroProfiler is particularly useful for identifying "spikes" in performance, where some frames take significantly longer than others to process.

Another symptom of degraded server heartbeat is increased latency (commonly known as ping). The longer the server takes to finish computing its tasks each frame, the longer it takes to process network data sent and received from clients. To check average ping for all players connected to a server, go to the Server Stats tab in the Developer Console.

Client Compute

The default client frame rate cap is 60 FPS. However, users can raise their frame rate cap up to 240 FPS on Windows.

Frame rate differs wildly between devices. For example, a high-end PC might be able to "brute force" a computational issue and only experience an imperceptible frame rate dip. If you test on lower-end devices, problems tend to be more severe and thus easier to notice.

To check the frame rate of your experience:

In the client, press ShiftF5 to show the debug stats summary.
In the Studio View tab, select Stats > Summary to enable debug stats.

Performance stats in Studio are skewed by the Studio application, so you should view the frame rate on the client if you have a production experience.
With the MicroProfiler, you can check the graph to see if the frame takes longer than 16.67 ms.

When evaluating frame rate, it can help to set the graphics quality to its maximum value to remove the effect of the frame rate manager. In the client, open the menu, click Settings, change Graphics Mode to manual, and raise graphics quality.

Server Memory

Try to keep server memory usage below 50%. Total server memory uses the following formula:

6.25 GiB + (100 MiB * largest_number_of_connected_players)

These numbers use powers of 2, so 1 GiB refers to 2^30 bytes and 1 MiB to 2^20 bytes.

For example, a server with 30 connected players has approximately 9.18 GiB of total memory. Servers gain memory when players connect, but don't lose it when players disconnect. If 10 players leave, the server still has 9.18 GiB of memory rather than shrinking to 8.2 GiB.

When servers shut down (for example, when they are empty or as part of the update process), their replacements start with the base amount of memory and begin scaling up as players connect.

Client Memory

There are several ways to check memory usage for an experience:

Open the Developer Console and switch to the Memory tab. This tab gives a breakdown of how memory is being allocated. Use the client rather than Studio to get the most accurate readouts.
Enable the Performance Stats view from the settings menu in the client to see an overlay with total client memory usage.

High memory usage is not necessarily indicative of a problem, but some indications that you may need to investigate more are:

A significant percentage of client crashes showing in the Performance Dashboard, particularly a sudden uptick that coincides with an update. Some number of crashes are expected, but you should investigate if your crash rates increase above 2-3%.
A crash occurs while testing on a device that you want your experience to support.

A significant portion of an experience's memory consumption on the client are from assets, such as images and meshes, loaded into graphics memory so they can be rendered. In the Developer Console, check the following labels:

GraphicsMeshParts - Graphics memory consumed by meshes.
GraphicsTexture - Graphics memory consumed by textures.

Load Times

There are no built-in tools for checking load times, but because they don't require millisecond-level precision, a stopwatch is usually all you need to understand your current baseline and check whether you made a substantive improvement. You can use a client script in ReplicatedFirst to get some sense of how your changes impact load times, but this script doesn't provide a complete, end-to-end measurement:


local startTime = os.clock()

game.Loaded:Connect(function()
  local loadTime = os.clock() - startTime
  local roundedLoadTime = math.round(loadTime * 10000) / 10000 -- four decimal places
  print("Game loaded in " .. roundedLoadTime .. " seconds.")
  print("Number of instances loaded: " .. #workspace:GetDescendants())
end)

For additional insight, enable Studio Settings > Network > Print Join Size Breakdown, which prints the top 20 instances by size and a percentage breakdown by instance type when you start the experience in Studio.