search

oddlama / nix-topology

🍁 Generate infrastructure and network diagrams directly from your NixOS configurations
https://oddlama.github.io/nix-topology
MIT License
576 stars 25 forks source link

Investigate why building services-overview.svg takes so long #6

Open SuperSandro2000 opened 7 months ago

SuperSandro2000 commented 7 months ago

I have a couple of hosts with each a couple of services. Building the derivation named services-overview.svg takes like 6 minutes on my host and is mostly busy with allocating memory but the process is not swapping. Maybe this is related to https://github.com/vercel/satori/issues/590 ?

oddlama commented 7 months ago

I'm not entirely sure what's the cause of this, but I have had similar issues too. I feel like it started as soon as I added PNG images to my nodes, but I haven't investigated it yet so I might just be imagining this. What makes me a bit skeptic about the linked issue is that they are discussing times of around 1-2 seconds while our render takes minutes..

The html-to-svg nodejs app is definitely stuck at 100% CPU, and it really just calls satori directly. So unless the base64 encode takes ages it's pretty likely that this is somehow related to what satori is doing.

nobodys-tools commented 7 months ago

I encountered a similar issue with non-.svg images and managed to significantly reduce build times by resizing all images to 150x150 pixels. I went from +5min to ~10sc (11 networks 24 devices/hosts and 50+ services, all with a custom image)

A potential workaround to address this problem is to automate the image resizing using a tool like ImageMagick. Images could be resized to 150x150 pixels by default unless they are specifically designated for standalone display using nodes.<name>.renderer.preferredType="image". In such cases, a slightly higher resolution, such as 300x300 pixels, could be used. (from what i can tell, the images seem to be limited to a maximum display size of 100x100 pixels in the rendered output anyway)