Thanks for reporting this potential issue. A new analytics model is enabled by default in Moodle 3.7.1, it sends reminders about upcoming activities
due to students. To do it, it iterates through the list of users in the site, so the first time the model is executed it can take some good time. After this first execution, the analytics API skips all the users who have already been analysed, they won't be analysed until +1 week (this is the default value for this model).
The system has been designed keeping performance in mind. The number of database
queries required to complete the task the first time depends on the number of users and the number of activities due for each of these users, but after that the number of queries should be really low (around 50 + the number of users in the site). The \tool_analytics\task\predict_models task shouldn't take that long, the equivalent cost of this task should be less than the cost of having each user in the site viewing their dashboard
- I am puzzled about the 1h15 required by core\task\analytics_cleanup_task. It shouldn't be that long as it is just running a few bunch of db queries. A couple of these queries have IN statements with a large number of params, this is the only possible cause I can think of. In any case, we are changing the "IN" approach of core_analytics\manager::cleanup method (the method executed by core\task\analytics_cleanup_task) in MDL-66498. You could try to pull the patch for 37 and try to execute the task again. I am really interested on this specific case because I have no idea of what can be wrong and I feel like I am missing something important, probably related to mysql/mariadb not handling efficiently a large number of params in an IN.
- What is the value of your "analytics | modeltimelimit"? The purpose of this setting is to split large processes like \tool_analytics\task\predict_models in batches. The default value is 20 minutes. It is possible that the system does not have enough time to go through the list of users in the site and it just processes a few of them, so the next time you run the task more users are processed. It would be great if you could paste the output or to summarise what can you see if you can't (the output may contain users' personal info). To know if the patch in the first point right above reduces the time taken by core\task\analytics_cleanup_task can help us narrow the issue to mysql/mariadb with IN.
- How many users do you have?
- Have you enabled any new model after the upgrade? These tasks are not new in 3.7, do you remember if they used to take that long?
- Is the students at risk model enabled? I ask it because I am assuming that the tasks are slower because of the new model, but it could also be that there is a performance regression after the API changes in 3.7.