Hello 
I have been developing game with Nakam for a while and was wondering is there a way to profile custom lua modules and its executions?
Like how much memory does it use, how much time does it take for functions to execute?
I know Lua that comes bundled with Nakama is stripped but it can use pure Lua 5.1 modules…Does that mean I would need for instance to include something like this:
Lua-Profiler
In order to profile code?
Thanks
Hello. Since the Lua VM is implemented in Go it follows that by profiling the go server would include the memory / cpu of the lua module itself but I am not sure if anyone has tried that yet and whether you’d see the details of the VM itself in such profile. Now how to profile your server depends on how you run it but maybe this answer will help you: Using pprof to profile - #2 by novabyte
Currently, i run server through docker-compose as it is still for development and testing.
And looking at the link you have provided, it seams there it will output all the extra logging data to prometheus where i should be able to take a look at it.
Another question related to this:
If i do profiling in another let say environment of Lua moduls, and the only difference between how it would be executed in that environment and how in Nakama is fetching from storage.
Would that be a feasable solution for profiling and can i hope that results i would see in that different enviornment would be similar in nakam.
Thanks.
I am back here, been digging a bit more.
The link you posted doesn’t help me much, it says overral consumption but not what actually is using it…You know in details. Is that a match handler,a custom game logic, or something else
So my new question is could nakam be enchanced on lua VM part and support debug module. On that way we could write our own profiles and profile lua code more throughly.
As hackish solution i am using now is:
- Use lua interpeter on windows. remove nakama calls or anything nakama related in scripts, wrap it with vanila lua codes or objects, and then load it with profiler to see what is causing bottle necks, not pleasant experiance .
Hi there,
what you are suggesting is limited by the VM features itself not by Nakama - in this case gopher-lua which is the only pure go implementation as far as I am aware of, so unless you are interested in adding debugging suport to gopher-lua I think your only option is to instrument your code with custom wrappers/markers/etc…
What i am suggesting is not limited by VM’s because normal Lua interpreter and VM has that option ( debug.hook ) modules added, but the creator of Gopher Lua implementation has disabled that option for the sake of stability.
As you can see in this PR SetHooks
Having debug.hook would give us ability to write custom modules/wrappers inside of nakam and create our own Lua profilers
Right now only way to profile Lua code for me is to strip code from nakama calls or create dummy module with nakama implementation and run it through native Lua interperter so i can profile it…It is not the greatest or most pleasant way but it is not great either.
So adding a little bit more of debug things could go a long way
Before it is suggested to switch to TypeScript or Go, there is a reason some of us devs choose to work with Lua rather than Go or TypeScript.
Not suggesting switching to TypeScript, Go if you want/need to use Lua it’s your choice and I agree it would be great if Gopher Lua supported debugging but what is that you are suggesting that should be done in Nakama ?
Exactly that, investigate or maybe research alternative ways to provide us a more debugging options…
Like that PR which adds option of having debug.sethook and getInfo which would open a door for us to have a custom module based profile which than can give stats like this:
TOTAL TIME = 0.030000 s
| FILE : FUNCTION : LINE : TIME : % : # |
|---|
| map : new : 301 : 0.1330 : 52.2 : 2 |
| map : unpackTileLayer : 197 : 0.0970 : 38.0 : 36 |
| engine : loadAtlas : 512 : 0.0780 : 30.6 : 1 |
| map : init : 292 : 0.0780 : 30.6 : 1 |
| map : setTile : 38 : 0.0500 : 19.6 : 20963 |
| engine : new : 157 : 0.0220 : 8.6 : 1 |
| map : unpackObjectLayer : 281 : 0.0190 : 7.5 : 2 |
| ui : sizeCharLimit : 328 : ~ : ~ : 2 |
| modules/profiler : stop : 192 : ~ : ~ : 1 |
| ui : sizeWidthToScreenWidthHalf : 301 : ~ : ~ : 4 |
| map : setRectGridTo : 255 : ~ : ~ : 7 |
| ui : sizeWidthToScreenWidth : 295 : ~ : ~ : 11 |
| character : warp : 32 : ~ : ~ : 15 |
| panels : Anon : 0 : ~ : ~ : 1 |
|---|
As your own investigation shows the only way to do this is to improve the debugging options in Gopher Lua itself, which as you’ve found out rests on a PR that is currently open in that project. Hopefully it will make it to a release sometimes soon and then we can expose the functionality in Nakama.