I've used RPi 3s for my printers thus far. I'm expanding my shop to 10+ printers.
What is the general wisdom around sizing how many instances of Octoprint a device can handle?
Sizing based on CPU, Memory, bus speed for the USB.
Anyone have experience to share?
I can not personally help from exp, but I did watch this youtube vid and if I recall it correctly this guy had 3 printers running from one rasppi. check it out:
Hope that helps....even a little
Personally, I would dedicate one Raspberry Pi 3B (no "+") for each printer you're running simultaneously. The price tag for me isn't a problem as compared to the gamble of losing four print jobs at once if it crashed, all that filament, the time printing and my setup labor for the session.
It makes things easier to test "what if?" scenarios since you can compartmentalize something like "let's install Klipper and compare with the others". Anecdotally, it's rumored to produce better surfaces since it pushes some of the work from Marlin back to the Raspi so there's no more delay-related blobbing.
My single rig runs Conky on the LCD so I can watch the core load in realtime. With a camera installed and streaming back to the browser, that activity consumes 100% of one of the cores itself. Without the camera, the browser load is still fairly high by comparison with the serial tasks of the RAMPS board.
If I'm load testing, what are the key resources I should monitor for an OctoPrint instance,
CPU, Mem, any processes in particular?
CPUs (all cores), memory, available drive space, network activity, swap space, file descriptors, connections to OctoPrint
I'm looking for the best way to 'stress test' the serial connection.
Use a mock printer and send it some sort of complex gcode maybe?
Sure, the VIRTUAL printer that's available is easy enough to setup. I've used it before. And then you can beat it up by throwing unexpected conditions in the form of debug commands as entered into the Terminal tab.
In the past, "crosstalk" has been a problem for, say, Ethernet (twisted pair) wiring. One pair of wires can accidentally induce false signals on another set of wires. The more twists-per-foot, the less the negative effect can be for crosstalk.
But a typical serial (USB) cable for your printer only has one pair so crosstalk isn't the problem. What is a problem is the square-looking nature of what's being sent from the stepper motor circuits. Square waves generate a lot of electromagnetic noise given the abruptness of the changes. So the stepper motors are electromagnetically noisy and the serial like can pick up on this, causing line errors.
How to test? Get a cheap (unshielded) serial cable with no ferrite coils on it, the longer the better.
The virtual printer won't be a proper stress test though - it runs in the same process as OctoPrint itself and hence will throttle the serial connection due to the python process having to swap between OctoPrint and it all the time.
What I do for speed tests is connect a real printer and upload to SD card. You could also just use an Arduino with disabled cold extrusion prevention and such and push data there.
I'm looking at SOC solutions. Theoretically, would their be a performance hit on a 32bit vs 64bit system? (Other than RAM limits)
Test Conditions :
I used nmon to monitor CPU and memory usage. The results got as high as 75% in one core, but overal peaks at ~50% the transfer speeds didn't change. I did start getting timeout errors if I reloaded webpage with c
Ctrl-F5 and reopened OctoPrint in the browser.