[PERFORMANCE]: IMPORTANT SQL performance issues in version 28.0.10

[section1]

Hello
I update the instance of NC from last 27.x to 28.0.10 and we see very big performace issues with Mysql. This is related to calendar/Caldav.
We see queries that takes ~90secs to complete with calendars that have aprox. +3000 events, causing lots of disks Reads I/Os and CPU usage.

The slow query:

SELECT `c`.`id`, `c`.`calendardata`, `c`.`componenttype`, `c`.`uid`, `c`.`uri` FROM `oc_calendarobjects` `c` WHERE (`deleted_at` IS NULL) AND (`c`.`classification` = '0') AND (`lastoccurence` > '1727362874') AND (`firstoccurence` < '1727363174') AND (`c`.`id` IN (SELECT DISTINCT `op`.`objectid` FROM `oc_calendarobjects_props` `op` WHERE (`op`.`calendarid` = '81') AND (`op`.`calendartype` = '0'))) ORDER BY `id` ASC

If i run this query in the mysql console returns :

66 rows in set (1 min 26.808 sec)

The oc_calendarobjects of that calendar id returns this:

SELECT COUNT(*)   FROM `oc_calendarobjects` WHERE (calendarid = '81') AND (calendartype = '0');
+----------+
| COUNT(*) |
+----------+
|     3261 |
+----------+
1 row in set (0.016 sec)

Most of the time i see various queries like this one but with different calendarid running at the same time using lots of CPU and disk I/O.
The weird part for me is that when i check the logs i see this line:

"PUT /ocs/v2.php/apps/user_status/api/v1/heartbeat?format=json HTTP/1.1" 204 - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36" 0 86

The last number(86) is the second that the request spent(%T of apache logformat ), reading the api docs about
apps/user_status/api/v1/heartbeat only says "Keep the status alive". I think is something related to the users status
that check if exist a meeting in that period and depends of that query results sets the user status ?
can disable this ? any help is welcome, thanks.

[section1]

I found this "feat(user status): automate user status for events" #40615 .
it's possible to disable this feature? or at last resort modifying the code with a workaround to disable it? thanks

[solracsf]

it's possible to disable this feature?

Disable user_status app.

[section1]

Thanks @solracsf i will try this!

[section1]

Well running the same SQL query now takes 1.112 sec so i don't now if create an index or what what isn't an issue anymore...i close this case for now.