I’m “calibrating” the FBOS v9.2.1 Farm Event “capacity” limit
By “calibrate” I am assuming you were just running a theoretical benchmark, correct? Or are you trying to accomplish a real-world use case? Can you tell me more about the FarmEvent you were trying to use? Was it that you created 9,000 FarmEvents in the database (), or you created a FarmEvent that had 9,000 points of execution? I like to evaluate bugs on a severity:likelihood scale, and although this is high in severity, it seems low in likelihood. If I am understanding the issue correctly, it might be better to set limits on this resource, which currently has few unlike logs or points.
The long-term “forever” solution to this is to re-write the FarmEvent data structures to use lazy evaluation. Right now, the system is already pretty strained with relation to event scheduling, to the point that some parts of the FarmEvent handlers had to be written in C (never a good sign). It’s been a while since I’ve had to look at that part of the codebase, though and I may need to re-visit to refresh my memory.
I’d be more in favor of setting a limit elsewhere in the stack rather than putting more fuel on the fire for performance issues, especially now that RPi0 devices are deployed. We’ve done similar things for points and logs.
- Express devices are very resource constrained and might be adversely affected by having that many points. We could change the limit for
rpi3 only, but it would be nice to maintain parity between models as much as possible.
- The frontend as it is currently designed probably can’t handle that many events. How did the web app perform under these conditions?
If you really need this feature I can take a deeper look. I think I might not be understanding the situation entirely.
expected max for total Farm Events is spec’ed at ?
Usually we wait for events like this to happen before we set hard limits, although you may have shown there is a need. Some of the limits were set here: https://software.farm.bot/v9/docs/account-limitations