4. CPU timeout history and server data

CPU timeout history and server data


  • There are several folks who suspect their timeouts are related to server conditions and not necessarily their code.

    I think one thing that could be very helpful for diagnosing timeout issues is some sort of data about how often they are occurring for others on the server. If you could see a history of your rate of timeouts perhaps together with the average rate on the server over a given time period, that would be excellent. I don't think the timeouts due to extraneous causes are a big deal if they are affecting everyone to the same degree. It would also be nice not to sink time into investigating the cause when it turns out to be outside the scope of your code.

    I don't know how feasible this is, but if it is, it would be greatly appreciated.


  • I wish I could + 100

     


  • And when you kill the code, a stack trace along with some sort of info would be most helpful.

    We could create a standard function named "iGotKilled()" or something and it could be called just prior to killing the process. It might even be the way you kill the process and let it die somewhat normally.

    That function (could also be called "iAmMelting()") would be able to write whatever the Player wanted to put into Memory and it would be available for the next startup so the code could send a report or analyze it on the Player's clock (literally).

    Obviously, I have not worked out all the issues with this, but just execution without any records of why the offender was killed is just not sporting.

    Thanks, Great game so far.


  • I also noted in another thread that the current message isn't helpful at all. For example my code runs at an average of 3 ms / tick and it runs fine for 2 weeks, then suddenly I get a message that I reached timeout, but without any further information on the issue. This leaves me with zero information on where to start and no way to test any changes that I would possibly implement. And considering that the code otherwise runs just fine, I will definitely not start poking into the dark.


  • My profiling code showed, that a simple Move (without path, just one direction) or Pickup can need 20ms. To execute the first line of the mainloop can need 120ms!

    If you detect such high cpu usage at the beginning of the mainloop, then most likely all other operations would also be very slow. You might consider skipping that tick - or at least, just execute what's absolutely necessary. Otherwise it's wasting your cpu time in bucket with a timeout.

    So, if it's not in your hand, you can find that out easily by looking up CPU-time at the beginning of the loop.

    For other cases, I've found that Memory is saved even after a timeout! So you can write your current state/position into Memory all the time, removing it at the end of the loop. If your script was cancelled by timeout, you can fetch the last state/position from Memory the next tick.

    However, it would be useful if the system would give us a stacktrace to lookup the last position before timeout.