Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Measure/improve CPU load for rapid-fire status requests #224

Open
SamuelPozzobon opened this issue Dec 29, 2024 · 3 comments
Open

Measure/improve CPU load for rapid-fire status requests #224

SamuelPozzobon opened this issue Dec 29, 2024 · 3 comments

Comments

@SamuelPozzobon
Copy link
Contributor

Hello,
I have recently discovered a potential CPU leak when a player is continuously refreshing the server list.

2024-12-29.17-03-09.mov

The console is also returning the following error:
[client=0000000001] Timeout
[client=0000000002] Timeout
[client=0000000003] Timeout

@meyfa
Copy link
Owner

meyfa commented Dec 29, 2024

Nice catch. I was able to reproduce this on my machine. However, I couldn't click Refresh fast enough and had to hold down F5 for a while before it suddenly happened.

I'm not sure what causes this, but the CPU went back to idle after a few seconds, so I don't think this is a big problem.

@meyfa
Copy link
Owner

meyfa commented Dec 31, 2024

I rewrote the network stack (#230, #231, #232) to improve performance, and while this can still be reproduced, the sockets are now handled more efficiently and at least in my testing the CPU usage drops back down much more quickly now. Also, this is basically a DoS attack, so I guess some performance impact is expected.

I'll go ahead and close this, but feel free to re-open if you disagree and we can discuss solutions.

@meyfa meyfa closed this as completed Dec 31, 2024
@GitMensch
Copy link
Contributor

If you can still reproduce it by holding F5, then this would be a very nice option to use perf record -p $(pgrep cobolcraft) (you can also start the recording for the process via hotspot) before pressing F5 and keeping it pressed, then stop the recording shortly after the CPU went down again.

I'd be interested to see where the performance is (and how this changes between GC 3.2 and 3.3, if any).
Again I guess there will be possible optimizations on both libcob/codegen and COBOL side.

Maybe reopen for the perf analysis?

@meyfa meyfa reopened this Jan 6, 2025
@meyfa meyfa changed the title Found a possibile CPU leak Measure/improve CPU load for rapid-fire status requests Jan 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants