It looks like some users pointed at using SQLite as the main cause of their problems, and that using MySQL improved significantly the performance. But it is not clear that was the main cause…
There was a more recent thread here, but I’m not sure of the conclusions:
So, anyone knows if the performance issues were confirmed, and what’s the state of it in recent versions of Kanboard?
i run on mysql. server is on local lan, an ubuntu VM on an older hyperv server.
all my users are on i3 12th gens., no issues with performance. the bottleneck comes down to rendering the board on the users workstations and cpu single core performance. the i3-12th with built in graphics works great.
this is with no filters on viewing the board - tasks are fully expanded (not collapsed) - all open tasks & swimlanes up to 300-400 tasks. 34 columns , 7 swimlanes. all my tasks are work orders generated in an erp system on ms sql. i then sync each work order over to kanboard. work orders contain extensive instructions (in markup) for manufacturing individual parts. there are sub tasks on each main task. tags on each task. users assigned. so on board view all that info is there.
im still on 1.2.12. this is because i have ms sql/mysql backends sync both ways with python and php - some scripts on ubuntu, some on windows. it would take some work to get my scripts updated for newer versions of php and possibly python.
You read correctly
SQLite is the bottleneck as soon as you have multiple parallel users since SQLite is filebased and only one process/person can write to a file at the same time
Kanboard keeps track of a lot of activities for example to provide a change-history for tasks
These activities create constant strain on the database.
MySQL and Postgres don’t have this constraint and won’t be an performance issue there.
After that the amount of tickets in a board becomes the limiting factor in the browser.
We mitigate this with an “active” work board and then separate “Archive”- and “Ticket-Pool”-Boards