overextended / ox_core

Player and vehicle management and persistence for FiveM.
https://overextended.dev/ox_core
GNU Lesser General Public License v3.0
152 stars 124 forks source link

Clarification on ox_core Performance Spikes Observed in Profiler #173

Closed Primordial-Devv closed 1 month ago

Primordial-Devv commented 1 month ago

Hi there,

First off, thank you for the amazing work you’ve done with ox_core. It’s a great tool for development, and I truly appreciate the effort that has gone into this project.

I am a developer currently testing and experimenting with ox_core on my development server. I recently started monitoring its performance using the built-in FiveM profiler. While the overall performance is generally excellent, I noticed some behavior that left me with a few questions, and I’d like to ask for your insights.

Specifically, I’ve observed the following in the profiler:


This pattern isn’t constant but occurs periodically. While this isn’t currently causing major issues on my development server, I was curious if these occasional spikes are expected behavior due to the nature of ox_core, or if they might indicate something worth investigating further.


Key Observations


My Questions

  1. Is this variability normal for a framework like ox_core, or could there be an underlying process that causes these spikes at specific intervals?

  2. Should I be concerned about these occasional increases in processing time, especially in a development environment where I aim to maintain high-performance standards?

  3. Are there any known strategies or optimizations to reduce these kinds of performance variations?

I’m aware that some variability in performance is normal, but I wanted to better understand the expected performance range for ox_core and ensure everything is running as intended in my development environment.


Environment

ox_core version: 0.31.2 Operating System: Win 11


Thanks again for the great work, and I look forward to your response!

Best regards, Primordial Studio

thelindat commented 1 month ago

Initial assumption is that it's occurring during a database query.

Most frameworks rely on an external resource (i.e. oxmysql) which will generally display that cpu spike instead.

I would need to see the profiler and know when these spikes are occurring, how many people are connected, and whatever other information seems relevant. There's a few other things I can think of off the top of my head that might spike, but I'd rather get more information first.


This could also just be the js runtime being kind of bad; you might want to test the experimental nodejs v22 build.

https://runtime.fivem.net/artifacts/fivem/build_proot_linux/feature/nodejs_and_v8_update/ https://runtime.fivem.net/artifacts/fivem/build_server_windows/feature/nodejs_and_v8_update/

Primordial-Devv commented 1 month ago

After running some tests, I can confirm that the spikes occur specifically when SQL queries are being executed. Without the SQL queries, ox_core runs quite smoothly at around 0.04ms to 0.06ms on average.

In the profiler, the highest spikes I observed without SQL queries were around 0.06ms. The performance seems consistent otherwise.

Thanks again for your guidance, and please let me know if there's anything else I should check or further investigate.


Best regards, Primordial Studio

thelindat commented 1 month ago

Try the nodejs update I linked and you'll probably have a more consistent ms

Primordial-Devv commented 1 month ago

I’ve tested the artifact integrating Node.js 22 as you suggested, and I can confirm that it does indeed help reduce the runtime's overhead slightly. With this update, I now see an average performance of around 0.04ms, which is an improvement over the previous values.

Thanks again for the suggestion, and let me know if there’s anything else you think I should look into!

Best regards, Primordial Studo