As part of the release, performance optimizations are introduced back into the product as a result of a customer issue or internally found problem. The Blackboard Performance Engineering team is responsible for refactoring under-performing areas of the application and verifying regression improvements based on the optimization.
LRN-65446: Commit Frequency In Stats Procedures is too high
The commit frequency in several of our stored procedures was way too high, causing heavy load and disk I/O on the DB server. This has bee resolved an DB IO load has been significantly reduced.
LRN-65307: Connect User Sync task causes db deadlocks, hundreds of threads causing system instability
The periodic Connect user sync task and the related lifecycle dispatcher task are generating massive numbers of Oracle deadlocks which caused Learn to run slow and be unstable.
LRN-65445: Delete query causing full scans on eud_item_recipient table
The delete query in question and other queries accessing the eud_item_recipient table performed slowly because of an inefficient data access patter (full table scan).
Extreme application locking waits for USER_MAPPING queries
Large amounts of application locking waits occur because a very slow query that was taking 1500+ seconds to run. This fix makes the query runs in a fraction of the original time, which will dramatically reduce the amount of locking waits.
Massive build of ACTIVE DB Sessions stuck on slow system_roles_entitlement CONNECT BY PRIOR query
A large number of DB sessions were stuck while waiting for a system_roles_entitlement query and java side sorting. Performance was dramatically improved by moving the java based sort operation to the DB, and by updating the Learn UI to only load the Node List on request rather than by default.
Id type and unmarshallers can't handle maximum values permitted by NUMBER data type
Learn experienced system stability issues when a large amount of data was written to the activity accumulator because the auto-incrementing ID column was exceeding the largest number that the Learn persistence framework could accommodate.
LRN-62954: Cache framework doesn't have concept of positive misses, causing excessive database round trips for non-existent keys
Unnecessary load was placed on the database because we were querying for courses that users weren't a member of whenever a course membership cache miss occurred.
LRN-62955: Course membership caching ineffecitve in courses
Course membership cache events were being reloaded for every course request, removing the value of the cache. This has been corrected and significant performance improvements were observed as a result.
Excessive redo generated by use_only_graded_attempts_upgr in 9.1 SP8 ps1
Upgrading to SP8 required an upgrade to the gradebook_grade table that set the first and last graded_attempt_pk1. Large data volumes on the assessment and gradebook_grade tables coupled with an inefficient query execution plan used up the temp space.
Database load averages spike around expensive AVL_CONTENT_PER_CRIT_VW query
Learn database performance was severely impacted because of high I/O demands from a query accessing the AVL_CONTENT_PER_CRIT_VW view. The views and queries were refactored to greatly reduce the I/O demands
LRN-63055: Instutional Hierarchy operations causing excessive SQL execution
Interactions involving Institutional Hierarchy caused excessive DB query activity that impacted overal Learn performance.
Opening a Message sent to ~1800 recipients take up to 10 minutes
Messages with a huge number of recipients were extremely slow to display. The message storage and loading process was optimized to avoid lookups for recipient’s full names, and improve the efficiency of database queries to access data more efficiently.