ID:1883522
 Jun 27 2015, 10:35 am
|
|||||||
| |||||||
Would it be possible to somehow have a way in the code to automate profiling scenarios? Like just keeping a running profile of the current world, being able to take 1-1000 tick long profile snapshots, etc. This would be helpful in eliminating the need of giving somebody admin access to the world just so they can view the profiler in the middle of the round without asking for somebody to grab it for them.
| |||||||
|
Jun 27 2015, 10:38 pm
|
|
Lummox JR
  |
Hrm. I suppose a proc could be added to turn profiling on or off. I'm not fond of that as a solution but I can't think of any other method that would work. (However, that proc would have to turn the profiling on between proc calls, not instantly.)
|
What about possibility of being able to dump the current profiling information to file from a proc?
| |
Pomf123 wrote:
What about possibility of being able to dump the current profiling information to file from a proc? I'd think this is way easier to do, since that info is already available in file-friendly format. byond://?debug=profile (assuming client/Topic() calls ..() ) opens up a profiler in the default browser element within an interface, and since it's BYOND, it's writes that file to the BYOND cache. Sounds like it'd be easy enough for that same output to be available for output elsewhere. | |
Yeah, ?debug=profile and most ?debug/.debug commands do complain about debug access if you're not in admin cfg...
From what I've noticed, that doesn't stop .debug profile from from bringing up the profiler for non-admin users; it just doesn't give them the ability to refresh, just shows them existing data, has to close & reopen to get updated info.. Is there no way for the server to pool that same data, and provide a way to output the data in the browser format in some way (ftp())? | |
I was mostly talking about something serverside and automated. Though I guess i could probably just make up some sort of script for a dummy account to join and grab the info throughout the rounds.
| |
I wanted to bump this request as most open source codebases (for ss13 at least) would find it rather useful. The dissemination of profiling information is a rather important facet that currently just isn't seen in the open source ss13 community at the moment.
It's just not feasible to give profiling access to any average person since it is bundled with the ability to reboot the server. At the current time it comes down to either giving out access to reboot to many people, or leaving many coders to wildly speculate (and they simply love to make superstitions) about any perceptible lag without any basis in fact. | |
luckily, you can restrict access to that restart command.
world.Reboot() will have usr set and the reason arg set to 1 if that button is used. you can just return without calling ..() if they don't have the required permissions. https://github.com/tgstation/-tg-station/blob/ b44176769379679f9042a32bfd00909996008c93/code/world.dm#L135 If reason is 1, and usr exists, it was a client side debugging verb (.reboot) else, it was the DD panel on windows or a linux process signal that triggered the reboot. (/tg/ will trigger a reboot without the normal stuff when reason is 1 because it might be used during the server being broke, and the sleeps might never wake up or take for ever. This way admins and maintainers can restart the server in those cases when something is causing it to hang.) | |
On that note, you can also use world.SetConfig("admin") to programmatically configure the list of ckeys allowed to access client side debugging tools.
| |
That being said, a programmatic way to automate profiling every round or certain parts of rounds that we can then upload to the same place we put public game logs/admin logs/runtime logs, would be super fucking helpful.
| |
Bumping, this would be very useful.
| |