I don’t know if this is exactly the right category for this, but it’s not exactly a bug and I figured the scripting category would fit more technical questions like this. I currently have a cross server matchmaking system in my game for a ranked combat mode: Project Smash - Roblox
Ranked matches only take a few minutes to complete (based on session time, about 7.5 minutes) so the server is only open for a few minutes. All of my code is shared between the main place and the ranked place with packages, with only minor differences (which, on the server, pretty much boils down to a simple round system script). The main place has a compute efficiency around 180%, and yet the ranked place has a compute efficiency around 15%. The FPS graph shows that the average FPS is 45, bottom 10th percentile is 0 FPS and 50th and 90th percentile is 60.
I believe this is because the compute efficiency graph takes into account the overhead associated with creating and setting up the server as, like I said earlier, ranked matches do not last long and there is a disproportional amount of servers being created (as well as the server creation time is a much larger portion of the total server runtime than it would be in a server that lasts 6+ hours). To be sure, I set up an analytics system with Memory Stores and logged average, minimum, and maximum FPS of servers. The average in my analytics is 60, median is 60 as well, and the minimum does not even touch 30 on average. These analytics already represent over 300 server runtime hours. I also don’t do any heavy calculations on server startup myself, anything heavy-ish is initiated on player join so it should be proportional to CCU (thus, my main place should have a similar compute efficiency). Perhaps there are best practices that I’m not following for reserved servers? But, with a compute efficiency this low, you’d expect connection issues or obvious server latency, of which there’s been zero reports.
This is annoying because, for my ranked place, the chart is basically useless for diagnosing any actual compute efficiency issues.