block_grade_me_cache_data was taking quite a long time to run and causing a huge number of database operations. In our server with thousands of courses the result was this:
737589 reads,
120516 writes,
4 min 34 sec
The number was exactly the same compared to reset_block script so it seems that the block_grade_me_cache_data script does not just update the new information into cache but is doing the full reset. In other words, block_grade_me_cache_data and reset_block are currently basically doing the same thing.
Our IT department decided to remove whole plugin from our Moodle server after it got stuck couple of times. This was sad because from my opinion the Grade Me plugin is one of the best blocks available and will help my day-to-day teaching tasks a lot.
I investigated the code, and it seems that there are two small bugs in block_grade_me_cache_grade_data function in lib.php which will make the script to (instead of updating) reset the whole block_grade_me table and create dublicates from every quiz answer instance to block_grade_me_quiz_ngrade table. By default the script is run from cron every 15 minutes, which means lots of unnecessary database operations and the size of the database is growing quite much during the day.
The root causes for these problems are:
$lastrun = $DB->get_field('task_scheduled', 'lastruntime', array('classname' =>'cache_grade_data'));
Classname is incorrect. It should have the full name '\block_grade_me\task\cache_grade_data'. This means that the $lastrun is always empty and the course is always updated even though it has not changed at all.
After correcting the classname we still have problems when updating the ungraded quiz attempts to block_grade_me_quiz_ngrade. Currently we are building the quiz table from scratch every time when the script is run. This is correct behavior if we reset the whole cache (in other words if the function is called from reset_block script). If we want to do the normal update, we should not touch the block_grade_me_quiz_ngrade table at all. Especially because currently we just add new instances blindly into database without checking if they already exist which will cause creating multiple duplicates after each 15 minutes. New attemps are anyway updated to the table by event handlers right away after created. So, this one needs conditions to check if we are doing the whole reset or only the update.
I have corrections for these two issues and will create a pull request soon.
block_grade_me_cache_data was taking quite a long time to run and causing a huge number of database operations. In our server with thousands of courses the result was this:
737589 reads, 120516 writes, 4 min 34 sec
The number was exactly the same compared to reset_block script so it seems that the block_grade_me_cache_data script does not just update the new information into cache but is doing the full reset. In other words, block_grade_me_cache_data and reset_block are currently basically doing the same thing.
Our IT department decided to remove whole plugin from our Moodle server after it got stuck couple of times. This was sad because from my opinion the Grade Me plugin is one of the best blocks available and will help my day-to-day teaching tasks a lot.
I investigated the code, and it seems that there are two small bugs in block_grade_me_cache_grade_data function in lib.php which will make the script to (instead of updating) reset the whole block_grade_me table and create dublicates from every quiz answer instance to block_grade_me_quiz_ngrade table. By default the script is run from cron every 15 minutes, which means lots of unnecessary database operations and the size of the database is growing quite much during the day.
The root causes for these problems are:
$lastrun = $DB->get_field('task_scheduled', 'lastruntime', array('classname' =>'cache_grade_data'));Classname is incorrect. It should have the full name '\block_grade_me\task\cache_grade_data'. This means that the $lastrun is always empty and the course is always updated even though it has not changed at all.After correcting the classname we still have problems when updating the ungraded quiz attempts to block_grade_me_quiz_ngrade. Currently we are building the quiz table from scratch every time when the script is run. This is correct behavior if we reset the whole cache (in other words if the function is called from reset_block script). If we want to do the normal update, we should not touch the block_grade_me_quiz_ngrade table at all. Especially because currently we just add new instances blindly into database without checking if they already exist which will cause creating multiple duplicates after each 15 minutes. New attemps are anyway updated to the table by event handlers right away after created. So, this one needs conditions to check if we are doing the whole reset or only the update.
I have corrections for these two issues and will create a pull request soon.