Hello,
We recently encountered the following case, which led to degraded reponse times on our Projeqtor instance.
* User creates new project
* Create 1000 activities in the project
* In each Activity , add a Link to all the other 999 activities of the project
=> This caused some very long delays whenever we would open the list of activities, or the detail view of one activity.
Obviously, this was an unexpected user behaviour, and we ended up force-deleting the project so that it could be restarted properly.
Note that when trying to delete the project through the user interface, this ended in server timeouts. It even blocked the application for all other users, while this operation was running ! In the end we had to delete linked elements directly in database.
This raises a few possible improvements (just some ideas, there may be better solutions) :
- for long lists, use pagination to avoid loading all the linked elements each time the parent activity is loaded
- only fetch ID and title of linked elements, not the entire object
- better management of parallelization between different users, somehow ??
Regards
- for long lists, use pagination to avoid loading all the linked elements each time the parent activity is loaded
It is very heavy work for very small benefit.
Possibly we can add limitaltion in number of linked items, will be more easy...
only fetch ID and title of linked elements, not the entire object
Possibly not as other data is expected (responsible, creator, creation date, ....) To display the information, we have to fetch it.
I'll have a look, possibly we can avoid fetching the sub-objects (notes, links, ...) of the sub-objects.
- better management of parallelization between different users, somehow ??
I don't understand
"parallelization" of what ?
"between different users" ? users who do what ?
"somehow" ? of what ?
The suggestions sound good to me - I just wanted to mention this situation we encountered, if it gives ideas of limitations to implement. Obviously it's not always possible to avoid each and every user mistake 🙂
For the "parallelization" part : what seemed odd is that for one project containing "too much" data, all users who were trying to use the application at the same time were impacted by slow response times.
Maybe it's bad server configuration , maybe too many full table locks in the application, ... many possibilities !
Of course for this point I don't really expect you can change anything easily.