I’ve setup a self-hosted version of the Rails app. I’m wanting to see if I can increase the current limitation of 1000 points / plants to at least 5000. Does anyone have some insight on why this limitation exists and what can be done to increase it?
The frontend cannot handle that many points as currently architected and implemented. At 1000 points/plants, performance of the frontend comes to a crawl and can easily make the browser tab unresponsive, especially on lower powered devices such as the chromebooks used in schools.
The Raspberry Pi and FarmBot OS, similarly, struggle with a high number of points. This is more apparent on the Raspberry Pi Zero included with Express bots, and less of an issue when using a Pi 3 or 4.
With a self-hosted setup you can absolutely increase the limit, but your mileage may vary!
I have a local club that does Open Source software development, with a particular bias towards Haskell and Ruby (pure functional and pure object-oriented languages).
We had a developer working on the problem on the side as an open source contribution, but he’s move on to other things. Our club is working on the issue, but it’s slow going as the Farm.bot codebase is mature and takes time to get to know.
The issue seem to be related to the React front-end. Self-hosting does not seem to make any difference. Anyone who has further insight into it, please send them our way.
The performance bottlenecks with the frontend (as far as I can tell) come from:
The refresh/recalculation/redraw of most to all of the app every time there is a state update (ie: every time there is a log or other message received by the frontend from the message broker). When there are a lot of resources, lots of things get recalculated. Some things could maybe be cached in some way, or some parts of the app could maybe only be selectively updated based on the type of state updates taking place. I would start with a React/Redux/web performance profiler tool to try and see exactly what operations are taking the most resources.
The SVG farm designer seems to have performance issues with a high number of plants/state updates as well. Early testing has shown this part of the problem may go away with the new 3D farm designer we’re working on. Either way, I wouldn’t recommend working on any optimizations in that area right now as the SVG stuff will be replaced with the 3D environment soon enough.
Chrome’s SVG rendering engine may have improved since the time the limitation was added. If you are self-hosting the app, you could search the repo for things like the POINT_HARD_LIMIT constant and try doubling the number to see what happens when the restriction is loosened. If the app is still slow after that many points, you will at least have a means of reproducing the issue locally. It also might be possible to improve performance slightly by using a custom SVG plat icon that has fewer XML elements, such as a simple circle icon (not sure, just an idea).