Analytics: Optimize low-end Android crash rates, server memory and CPU performance

[signal_zzz]

9/13 update: We noticed some discrepancies in the server CPU chart data, specifically related to Scripting, Physics, and Animation categories. We’ll be pushing out a fix next week. In the meantime, avoid optimizing those CPU time categories.

Just want to be transparent and thanks for your patience! We’ll post again when this is fixed.

---

Hi Creators,

Today, we are introducing two updates to help you:

1. Improve low end Android crash rates
2. Troubleshoot server memory and CPU time issues

Improve low end Android crash rates

As Roblox continues to grow internationally, it’s really important to make sure that your experiences play great on lower end devices. One of the most common reasons for crashes on low end devices is due to out of memory errors.

So today, we’re introducing a new insight on your Experience Overview page to help you identify if your experience is crashing frequently on <2GB memory Android devices. You’re eligible to see this insight if:

• 5% or more of your concurrent users are on <2GB Android devices
• Your <2GB Android crash rate is significantly worse than the average across all devices

You can also use the Filter By button on your performance page and in explore mode to view charts like client crash rate by OS and memory usage:

We’ve updated our documentation to more clearly explain how you can lower your crash rates.

Troubleshoot server memory and CPU time issues

We’ve added two new charts on the server tab of your performance page that break down server CPU time and memory usage by category. These charts can help you identify and address issues that may impact player experience:

1. High memory consumption can lead to increased server-side crashes.
2. High CPU usage can result in degraded server frame rate (heartbeat) and responsiveness

Here’s how you can use these new charts:

1. Identify the categories that are consuming the most resources

2. Select the category in the drop-down to view the sub-categories (e.g., physics, system). You can also use explore mode to slice and dice the data further.

3. Continue actioning in the MicroProfiler and Dev Console to analyze shown tags and subcategories, focusing on problem areas that could be optimized for efficiency when updating your experience.

Select the Filter By button on the server tab to view all charts by percentile. For example, compare the average vs. p90 performance metrics to see how much worse your worst cases are and if issues are consistent across player experiences.

We’ve added updates to our Performance Analytics documentation and Performance Optimization guide that guides you through this process.

Please let us know if you have any questions or feedback about today’s launch.

Thank you.

[ChiefWildin]

These new server usage charts are awesome, thank you! Client side when?

[MaxGamingYT129 (Max)]

Wow, that’s a nice update, will it be possible to see in the future what device they use ?

[Iliuminatis (・ロ・)]

Is it even possible to optimize for <2GB memory android? I’ve tried Roblox on 3GB android phone and it was unable to run any experience without crashing within a minute.

[focasds]

And what does the Compute Efficiency show? As much as I read the documentation for it, I can’t understand where the graph gets it’s values from. Is it tied to the CPU Time and Server Memory?

1. What is bad and what isn’t?
2. Which is the target goal for the CPU Time and Server Memory?
3. When should I feel it’s ok to leave it like it is?
4. What is happening with physics taking most in it, does it include AnimationTrack played on Server?
5. Are Constraints too expensive on performance for physics? Are they constantly applying force?
6. I anchor all moving objects and stop scripts in my game when players are far away, I am unable to know what is going on still. What’s the limit that physics really have?

I need directions at this point, some guide that really goes deep into performance, on a public server in my game there are:

1. 300+ Awake Parts on a normal public server.
2. 1.3K Parts are not grounded.
3. 800 of those Parts are player characters.
4. 500 of those Parts are from animals in my game, they all have network ownership set to Auto.
5. When players join the game on StreamingEnabled many parts become active all at once during the spike lags according to GetNumAwakeParts.

This is not a feature request at all, I just need answers…

[imagineerrx]

There are many Experiences that run well on < 2 GB Android. If you receive the insight it means that your experience is doing particularly bad.

Turning on Streaming is one way to optimize client side resource usage.

[Avallachi]

I definitely miss being able to view the “concurrent users” graph in the server tab as it showed the difference from the previous period - a metric I frequently use to see where my game is headed.

[imagineerrx]

That still exists in the Client tab

[kaike351 (Pico)]

this new update is very helpful, Thanks!

[quazotheduck]

Here are some resources to help with performance optimization: Performance Optimization | Documentation - Roblox Creator Hub,
Instance Streaming | Documentation - Roblox Creator Hub,
Real world building and scripting optimization for Roblox

[Avallachi]

The “concurrent users” graph in the client tab does not show the difference from the previous period - only the graphs in the server tab do

[Iliuminatis (・ロ・)]

I have read those already, the issue is with others Roblox experiences that crash quickly on 3GB memory android phone. I would guess it is due to weak cpu/gpu, but I wouldn’t expect a better performance from a <2GB memory phone.

[XoifailTheGod (XNX)]

This is great but even in a default baseplate, there are still memory leaks within Roblox scripts mostly when a character dies even with the new PlayerCharacterDestroyBehaviour enabled

[imagineerrx]

I see the comparison chip in the Clients CCU chart, i’m confused on what is the gap.

[Boeufplume6771 (OverDsh)]

I love error, crash and bugs graphs. Especially the console error logs, so practical . It makes it so easy to quickly dispatch fixes.

[Avallachi]

This is what I see:

But I’d like to see these types of comparisons like I previously could in the server tab for the CCU graph:

[bloopyhere]

@imagineerrx

There are many Experiences that run well on < 2 GB Android.

Could you name them? Would love to see an example of what to do right! I’m also interested if these games “settle” on certain features or design choices to accommodate for said devices- a bit worried that the only games that can run on low end devices are games without a need for a dense map or high detail.

[imagineerrx]

Oh okay, I get it, we’ll see what we can do

[imagineerrx]

I can’t give out the names of Experiences which are doing well, you’ll have to trust me on this one.

I think < 10% of Experiences are seeing the < 2 GB Android insight… so… and this isn’t all the small Experiences, these are the largest ones too that are at the top of the charts.