The device watching mechanism does not scale well and might cause performance issues
Description
When subscribing via gNMI, a device sends one response for each path (per change or interval depending on the actually used stream mode). Currently, we spawn a new go routine for each of these responses to handle it. This does not scale well and could crash the controller as it can produce huge amounts of go routines for each device, even worse when trying to observe hundreds of devices at the same time (which is a likely real world use case). An option to deal with this issue is using a fixed amount of workers per device to listen to their own go channel and then forward subscribe responses to their channels (maybe including some kind of queue mechanism) instead of spawning an own go routine per subscribe response. Check gnmi_transport in this merge for more information
Expected Behavior
Actual Behavior
Possible Fix
Steps to Reproduce
Context
Your Environment
- Version used:
- Environment name and version (e.g. go v1.16.3 on FreeBSD 13.0-current):
- Server type and version:
- Operating System and version: