-
Notifications
You must be signed in to change notification settings - Fork 10
Added liveview memory usage + estimate of the assigns #312
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
base: main
Are you sure you want to change the base?
Added liveview memory usage + estimate of the assigns #312
Conversation
…ore useful information
Process.send_after(self(), :assign_memory_usage, 2000) | ||
|
||
raw = | ||
case :erlang.process_info(self(), :memory) do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self()
in this context returns a PID of SidebarLive
LiveView - not debugged LiveView process
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad @kraleppa wasn't thinking - targeting the lv_process.root_pid
which i believe will be the correct one now.
|
||
assigns_size = | ||
try do | ||
words = :erts_debug.size(socket.assigns) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As above - you are calculating here size of SidebarLive
assigns
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep - thanks. Followed other example of using the ChannelService to pull in the node and then calculate the size on that assigns. @kraleppa
Made changes to fetch correct PID / correct Assigns. Now with the correct data the pre garbage collection values stabilize with the post garbage collection values as expected (but you can see the initial spike which may be helpful). Maybe as a further enhancement a simple mem graph could be implemented. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, for the contribution - my only concern with this is the fact that I'm not sure if this information should be inside the sidebar from the UX perspective 🤔 Adding this info lefts less space for components tree and nested LiveViews. On the other hand I can't come up with a better place to display this information.
I'll talk with our designer next week, if you had any other ideas about positioning them feel free to share them. Anyway this will have to wait till we deploy v0.2.0 (it may cause some conflicts)
Process.send_after(self(), {:assign_memory_usage, pid, node_id}, @memory_poll_interval_ms) | ||
|
||
raw = | ||
case :erlang.process_info(pid, :memory) do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please create wrappers for these erlang function in services/system
- we may want to mock them in the tests and there are some rumors that LiveView might get its own Debug module, so we want to have an easy way to swap them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kraleppa added in the wrappers.
I did opt to skip the following in the ErlangService, but it can be easily added if you prefer.
words = :erts_debug.size(assigns)
words * :erlang.system_info(:wordsize)
Added some basic memory usage for Liveview & also assigns.
Because the GC can have such an impact on the size, i've opted for two values 1 before & 1 after.
I wasn't quite sure on how to estimate the assigns size, so i've taken a stab (please note this is not just the user defined area of assigns).
Also after some initial testing I found that adding a simple poll to re-gauge memory usage after hydration, was more useful than the initial numbers that were returned.
I also didn't find much in the way of tests for testing the main dashboard here, so didn't add any tests. But please push back if they are required / for any other changes.
Related to issue: #248