Session in DB
Doesn't really make sense to me. The bottle neck is database, not Traccar.
In this case the bottle neck is not the database is the server ram. If you generate a report with a lof of units for a long period of time it can crash the server because it get's out of memory. The database is not affected.
Well, in that case your case is very unique. We never had such problem on any of our servers.
@JCardus
How many devices are registered on traccar server and what are the specs of the server ?
5k, I'm using aws, an elastic beanstalk with single instance env. m5a type, 8 gb, more than enough if you don't start hitting big reports.
From what i read through the forum in the last few years is that people run into troubles when a traccar server hits about 5k devices (for myql or anything else). I always wondered why not just and a new server instance instead of trying to stretch the maximum..
@Track-trace can you please provide some supporting references for "people run into troubles when a traccar server hits about 5k devices".
In General i read about 5k in these topics.
https://www.traccar.org/forums/topic/unresponsive-server-while-cleaning-old-data-lock-wait-timeout/
https://www.traccar.org/forums/topic/traccar-like-a-gps-listener-3000-units-up/
https://www.traccar.org/forums/topic/server-resource-optimization/
But actually i was thinking about two topics where a user had 5k devices and stated the mysql issues he had where that the database got huge rapidly. Which slowed down performance. And another topic where the webinterface got slow while loading such a huge amount on the map. But i could not find those topics now with the search function.
When you get to thousands of devices you need to configure Traccar and database correctly. It obviously requires some technical expertise.
As for slowdown when you have 5k devices in the web app, of course it's going to happen. It's just limitations of the browser. It's going to be slow. But that's why we have filtering. And we also have clustering in the new web app now.
I'm thinking about creating a second traccar instance just for reports, something like redirecting the request to another server when the path is /api/reports/.
Assuming the traccar memory cache problem is not an issue I would need to store the Jetty session in a shared store (the database for example) for the authentication to work.
Does it make sense for a PR for it? Are there other options to "scale"?