Track number of queries in tests

[ghickman]

We're starting to see a few performance issues recently, and particularly with the removal of an implicit query (#3323), and the removal of orgs from urls (#3312).

It would be useful to have some query counts in our tests, but it's not clear how many pages we should do this for. Lets err on the side of adding them to the success test case for each page to start with.

The homepage has various objects in it so it's an obvious first target to try this out.

Templates:

• _job_request_pagination.html
• _job_requests.html
• index-authenticated.html
• index-unauthenticated.html
• interactive/analysis_request_create.html
• interactive/analysis_request_detail.css
• interactive/analysis_request_detail.html
• interactive/publish_request_create.html
• interactive/publish_request_create_locked.html
• interactive/report_edit.html
• interactive/report_edit_locked.html
• job_detail.html
• job_request_create.html
• job_request_detail.html
• job_request_list.html
• job_request_pick_ref.html
• login.html
• org_detail.html
• org_list.html
• outputs-spa.html
• pipeline/require_name.html
• project_detail.html
• project_edit.html
• project_release_list.html
• project_repo_list.html
• project_report_list.html
• release_detail.html
• settings.html
• sign_off_repo.html
• snapshot_detail.html
• staff/analysis_request_detail.html
• staff/analysis_request_list.html
• staff/application_approve.html
• staff/application_detail.html
• staff/application_edit.html
• staff/application_list.html
• staff/backend_create.html
• staff/backend_detail.html
• staff/backend_edit.html
• staff/backend_list.html
• staff/dashboards/copiloting.html
• staff/dashboards/index.html
• staff/dashboards/projects.html
• staff/dashboards/repos.html
• staff/dashboards/repos_with_multiple_projects.html
• staff/index.html
• staff/job_request_detail.html
• staff/job_request_list.html
• staff/org_add_github_orgs.htmx.html
• staff/org_create.form.html
• staff/org_create.html
• staff/org_create.htmx.html
• staff/org_detail.html
• staff/org_edit.html
• staff/org_list.html
• staff/org_project_create.html
• staff/project_create.form.html
• staff/project_create.html
• staff/project_create.htmx.html
• staff/project_detail.html
• staff/project_edit.html
• staff/project_feature_flags.html
• staff/project_link_application.html
• staff/project_list.html
• staff/project_membership_create.html
• staff/project_membership_edit.html
• staff/publish_request_detail.html
• staff/publish_request_list.html
• staff/redirect_detail.html
• staff/redirect_list.html
• staff/repo_detail.html
• staff/repo_list.html
• staff/report_detail.html
• staff/report_list.html
• staff/researcher_edit.html
• staff/user_create.html
• staff/user_detail_with_email.html
• staff/user_detail_with_oauth.html
• staff/user_list.html
• staff/user_set_orgs.html
• staff/workspace_detail.html
• staff/workspace_edit.html
• staff/workspace_list.html
• status.html
• workspace_analysis_request_list.html
• workspace_backend_files.html
• workspace_create.html
• workspace_create_error.html
• workspace_detail.html
• workspace_edit.html
• workspace_file_list.html
• workspace_latest_outputs_detail.html
• workspace_log.html
• workspace_output_list.html
• workspace_release_list.html
• yours/analysis_request_list.html
• yours/org_list.html
• yours/project_list.html
• yours/workspace_list.html

[ghickman]

This is complicated by us doing several queries in our templates.

To track both we have to wrap both the view call and rendered_template in the count call:

with django_assert_num_queries(n):
    response = MyView.as_view()(request)

…

with django_assert_num_queries(m):
    response.rendered_content

This is a good time to try out methods for ensuring we don't pass rich objects to the template. Maybe a method on a model that produces a dict? (or a dataclass/attr's class?)

[lucyb]

Could we narrow down the scope of this ticket to just one of these ideas, please? Perhaps focusing on adding a test for the homepage for now or for one of the pages that Tom O is about to change?

This change could then be used as a pattern for applying to future tests when we next come to make changes to any views/templates.

[ghickman]

There's only two ideas here, count queries and push all queries to the view to avoid paying the cost of template rendering in tests. The work for this ticket is really working out a method or tools that we like for doing these and then applying them to each view, using the list above to track progress.

[mikerkelly]

Another approach is to use Honeycomb to profile which pages are actually slow in production then raise issues to spot-resolve them. That's possibly more targeted at problems. django-silk is a useful profiling tool that might be a more natural fit than home-rolling performance metrics within the testing framework.