slowly dashboard

Viewing 7 replies - 1 through 7 (of 7 total)
  • Maizul

    (@maizul)

    2 weeks, 3 days ago

    Hey @kouiderbounama ,

    On a standard Tutor LMS setup, we have not encountered similar dashboard performance issues after the 4.0 update.

    We would appreciate it if you could share more information about your hosting environment, server configuration, and overall setup so our team can review the issue further and use the information for future improvements.

    Thread Starter kouider bounama

    (@kouiderbounama)

    2 weeks, 3 days ago

    the issue for big lms sites
    i have 23000 student and 41000 Enrollment
    i change host 3 times
    to fix this isseu i rollback to version 3.9

    Maizul

    (@maizul)

    2 weeks, 2 days ago

    Hey @kouiderbounama ,

    Thank you for sharing the additional details. Since your site has a large number of students and enrollments, it would be helpful if you could share a performance comparison between Tutor LMS 3.9 and 4.0.

    Real-world data from a large LMS setup like yours will help our developers better analyze the performance differences and identify areas for optimization in future updates.

    Thread Starter kouider bounama

    (@kouiderbounama)

    2 weeks, 2 days ago

    Hi Support Team,

    I’d like to report a performance issue with the dashboard loading speed. Based on our analysis, the bottleneck is caused by the way data is currently being fetched from the database.

    The dashboard queries student, course, and enrollment data item-by-item rather than in bulk. As a result, the query count increases proportionally with data growth, which is why the issue becomes noticeable at our current scale.

    Requested Action:
    Could you please optimize the queries for the dashboard page (e.g., using eager loading, batching, or JOINs) to reduce database round-trips and improve loading times?

    Thanks for your help!

    Thread Starter kouider bounama

    (@kouiderbounama)

    2 weeks, 1 day ago

    During the page render of the dashboard, the Tutor LMS plugin generated 88,374 SELECT queries, accounting for 99.9% of the total database execution time (75.69 seconds out of 75.71 seconds). The issue stems from an N+1 Query Loop where the plugin calculates course completion stats, student counts, and content IDs iteratively for each user and course rather than using bulk database queries or persistent object caching.

    ‘Based on the Query Monitor tool shown on the screen, there is a massive and abnormal load on the database caused by the Tutor LMS plugin (Plugin: tutor), generating a total of 88,408 queries and taking approximately 75.7 seconds to load.

    The most resource-intensive and slowest query callers are broken down as follows:

    TUTOR\Utils->is_completed_course

    Query Count: 39,877 queries

    Execution Time: 49.41 seconds

    Issue: This function is repeatedly called within the dashboard to check or verify course completion statuses.

    Tutor\Helpers\QueryHelper::get_count

    Query Count: 23,891 queries

    Execution Time: 18.88 seconds

    Issue: Calculates student/applicant counts for each course or section using unoptimized, non-cached database queries.

    TUTOR\Utils->get_course_completed_percent

    Query Count: 23,721 queries

    Execution Time: 4.43 seconds

    Issue: Computes course completion percentages via individual, separate queries for each course instead of executing a single aggregated database request.

    TUTOR\Utils->get_course_contents_by_id & get_course_content_ids_by

    Query Count: 358 queries each

    Execution Time: ~2.6 seconds combined’

    View post on imgur.com

    Thread Starter kouider bounama

    (@kouiderbounama)

    2 weeks, 1 day ago

    See these screenshots https://imgur.com/a/CVwtN9L

    During the page render of the dashboard, the Tutor LMS plugin generated 88,374 SELECT queries, accounting for 99.9% of the total database execution time (75.69 seconds out of 75.71 seconds). The issue stems from an N+1 Query Loop where the plugin calculates course completion stats, student counts, and content IDs iteratively for each user and course rather than using bulk database queries or persistent object caching.

‘Based on the Query Monitor tool shown on the screen, there is a massive and abnormal load on the database caused by the Tutor LMS plugin (Plugin: tutor), generating a total of 88,408 queries and taking approximately 75.7 seconds to load.
    Maizul

    (@maizul)

    1 week, 4 days ago

    Hey @kouiderbounama ,

    Thank you for sharing the detailed information and Query Monitor findings. Our team is working on improving the dashboard performance, and we appreciate your detailed feedback and analysis regarding this issue.

Viewing 7 replies - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.