Account limitation to 5000 points/plants?

@RickCarlino @jsimmonds

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?

Thanks in advance,


1 Like

The limitation is in place for two main reasons:

  • 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!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

@roryaronson @RickCarlino @Gabriel

Would you have some recommendation or key first steps to take to overcome the front end performance issues?

What part of the front-end code base is likely causing the performance issue?

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 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.

1 Like

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).


As you were the original dev Rick (which was an incredible achievement I might add - documentation is among the best I’ve ever seen) what other rendering options had you considered besides SVG?