# Too many query of schedules when access the courseware

**URL:** https://discuss.openedx.org/t/too-many-query-of-schedules-when-access-the-courseware/13391
**Category:** Site Operations Help
**Tags:** maple, how-to, api, tutor
**Created:** [July 11, 2024, 6:46am UTC](https://discuss.openedx.org/t/too-many-query-of-schedules-when-access-the-courseware/13391 "2024-07-11T06:46:49Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![icarrr](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/icarrr/32/300_2.png) [@icarrr](https://discuss.openedx.org/u/icarrr)
#### Post date: [July 11, 2024, 6:46am UTC](https://discuss.openedx.org/t/too-many-query-of-schedules-when-access-the-courseware/13391/1 "2024-07-11T06:46:49Z")

</div>

Hi everyone,

I’m currently working on improving the initial loading time for accessing courseware in our LMS at the path `lms-domain/courses/{course_id}[/+]+{var}[/]+)/courseware/`. On the first access, it takes about 2 to 5 seconds for the server to respond, during which the browser is just loading without displaying any content.  
 ![image](https://us1.discourse-cdn.com/flex020/uploads/openedx/original/2X/a/aa6d5a41e1007faf0cf6680ab757f90073f931d0.png)

To diagnose the issue, I used Sentry to trace the processes happening in the background. I found that there are too many actions checking schedules in the `schedules_schedule` table in MySQL.

 ![image](https://us1.discourse-cdn.com/flex020/uploads/openedx/original/2X/1/1c7eb805b2acac15e14d6f0abe83266dad50d034.png)

Here are my questions:

1. Why are these schedule checks being performed repeatedly?
2. Is there a way to disable these actions? I do not use the schedules feature or send emails to students.

Note: this is using maple version

---

<div class="post-metadata">

### Author: ![dave](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/dave/32/263_2.png) [@dave](https://discuss.openedx.org/u/dave)
#### Post date: [July 11, 2024, 7:20pm UTC](https://discuss.openedx.org/t/too-many-query-of-schedules-when-access-the-courseware/13391/2 "2024-07-11T19:20:07Z")

</div>

It’s possible that we’re either doing a check somewhere deep in a loop somewhere, or else we’re missing a select\_related and it’s re-fetching when someone’s looking at the schedule attribute off of an enrollment object.

Does Sentry give you a line trace of where that’s coming from exactly? It should hopefully be relatively straightforward to either cache with a request cache or add the select\_related if so.

---

<div class="post-metadata">

### Author: ![icarrr](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/icarrr/32/300_2.png) [@icarrr](https://discuss.openedx.org/u/icarrr)
#### Post date: [July 12, 2024, 5:43am UTC](https://discuss.openedx.org/t/too-many-query-of-schedules-when-access-the-courseware/13391/3 "2024-07-12T05:43:27Z")

</div>

@dave it’s coming from `lms.djangoapps.courseware.views.index:CoursewareIndex.get`

The following the query

```sql
SELECT `schedules_schedule`.`id`, `schedules_schedule`.`created`, `schedules_schedule`.`modified`, `schedules_schedule`.`enrollment_id`, `schedules_schedule`.`active`, `schedules_schedule`.`start_date`, `schedules_schedule`.`upgrade_deadline` FROM `schedules_schedule` INNER JOIN `student_courseenrollment` ON (`schedules_schedule`.`enrollment_id` = `student_courseenrollment`.`id`) WHERE (`student_courseenrollment`.`course_id` = %s AND `student_courseenrollment`.`user_id` = %s) LIMIT 21

```

---

<div class="post-metadata">

### Author: ![dave](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/dave/32/263_2.png) [@dave](https://discuss.openedx.org/u/dave)
#### Post date: [July 12, 2024, 2:13pm UTC](https://discuss.openedx.org/t/too-many-query-of-schedules-when-access-the-courseware/13391/4 "2024-07-12T14:13:11Z")

</div>

Okay, dug a little bit deeper, and it looks like this is the detailed stack trace:

```plaintext
/openedx/edx-platform/lms/djangoapps/courseware/block_render.py in get_block_for_descriptor(455)
  block.bind_for_student(

/openedx/edx-platform/xmodule/x_module.py in bind_for_student(617)
  wrapped_field_data = wrapper(wrapped_field_data)

/openedx/venv/lib/python3.11/site-packages/edx_when/field_data.py in __init__ (51)
  self._load_dates(course_id, user, use_cached=use_cached)

/openedx/venv/lib/python3.11/site-packages/edx_when/field_data.py in _load_dates(59)
  for (location, field), date in api.get_dates_for_course(course_id, user, use_cached=use_cached).items():

/openedx/venv/lib/python3.11/site-packages/edx_when/api.py in get_dates_for_course(196)
  schedule = get_schedule_for_user(user_id, course_id)

/openedx/venv/lib/python3.11/site-packages/edx_when/utils.py in get_schedule_for_user(19)
  return Schedule.objects.get(enrollment __user__ id=user_id, enrollment __course__ id=course_key)

```

Which probably means that we need to patch up this function to use the request cache:

> <https://github.com/openedx/edx-when/blob/9842a99ab0ce8a09d96673ea7bf2e7382a6fdfee/edx_when/utils.py#L13-L22>

There are other problems with that code and the way the model dependencies are working here, but that’s a problem for another day.

I am very coincidentally looking into Unit rendering time and XBlock runtime overhead related to a different proposal this week. I’ll see if this straightforward to patch.

---

<div class="post-metadata">

### Author: ![dave](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/dave/32/263_2.png) [@dave](https://discuss.openedx.org/u/dave)
#### Post date: [July 13, 2024, 3:18am UTC](https://discuss.openedx.org/t/too-many-query-of-schedules-when-access-the-courseware/13391/5 "2024-07-13T03:18:40Z")

</div>

I’ve started a PR with a fix for this here:

> <https://github.com/openedx/edx-when/pull/259>
>
> Calls to render a Unit were calling this function many times, even when
> schedule…s are not enabled. This was leading to noticeable performance
> issues in production, particularly for Units with many components.
> 
> I still need to test this properly, which is probably going to involve
> hacky looking mocking because of the weird model relationship this has
> with edx-platform (where it's actually importing the Schedule model
> from edx-platform).

@icarrr: Do you know if this particular trace you’re seeing is happening for a Unit with many components in it?

Please note that I’m taking some time off starting in the middle of next week, so this likely won’t be merged until the end of the month or so (unless someone wants to take over the PR and test/merge before then).

---

<div class="post-metadata">

### Author: ![icarrr](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/icarrr/32/300_2.png) [@icarrr](https://discuss.openedx.org/u/icarrr)
#### Post date: [July 15, 2024, 3:30am UTC](https://discuss.openedx.org/t/too-many-query-of-schedules-when-access-the-courseware/13391/6 "2024-07-15T03:30:48Z")

</div>

> [@dave](#):
>
> @icarrr: Do you know if this particular trace you’re seeing is happening for a Unit with many components in it?

@dave yes, this also happens in units with many components. It also occurs when navigating to other subsections.

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/flex020/uploads/openedx/original/2X/e/e0015f89e879bc75925b71fd11133ab15fe98297.png) [@system](https://discuss.openedx.org/u/system)
#### Post date: [October 13, 2024, 3:31am UTC](https://discuss.openedx.org/t/too-many-query-of-schedules-when-access-the-courseware/13391/7 "2024-10-13T03:31:21Z")

</div>

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
