Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce the number of proposals in pagination spec #3687

Merged
merged 1 commit into from
Sep 10, 2019

Conversation

javierm
Copy link
Member

@javierm javierm commented Sep 8, 2019

References

Background

We're getting a failure on Travis in one of these tests. Debugging shows the AJAX request rendering the first page (after clicking the "Previous" link) takes too long and sometimes it exceeds Capybara's timeout.

Objectives

Make the test faster so we don't reach Capybara's timeout.

Notes

After running the test thousands of times, the only way I've found to clearly reduce the number of times the test fails (reducing the time of the request by 0.4 seconds on average) is to reduce the number of records shown on the first page. Other experiments, like adding an includes(:author) to the query getting the proposals in the controller, or adding author: user to the create_list part of the test (so only one author needs to be fetched when rendering the proposals) show inconsistent results regarding performance.

Of course improving the performance of the partial rendering legislation proposals would be a better solution. However, after some debugging I wasn't able to find a clear bottleneck, so speeding up this part would be a complex task.

The test failed with the following message:

  1) Legislation Proposals Random pagination Random order maintained with pagination
     Failure/Error: expect(page).to have_content "You're on page 1"
       expected to find text "You're on page 1" in "CONSUL Language: عربى Bosanski Čeština Dansk Deutsch Ελληνικά English Español فارسى Français Galego עברית Hrvatski Bahasa Inggris Italiano Nederlands Polski Português brasileiro Pусский Slovenščina Shqiptar Af Soomaali Svenska Türkçe Valencià 中文 英文 Notifications My content My account Sign out Debates Proposals Voting You are in Collaborative legislation Participatory budgeting Help Go back A collaborative legislation process DESCRIPTION Description of the process SHARE twitter facebook google_plus DRAFT PUBLICATION 06 Aug 2019 FINAL RESULT PUBLICATION 12 Aug 2019 Participation phases Debate 02 Aug 2019 - 09 Aug 2019 Proposals 07 Aug 2019 - 09 Aug 2019 Comments 07 Aug 2019 - 10 Aug 2019 : Random Selected Proposal 32 for a legislation No comments • 2019-08-07 • Manuela1550 This law should include... I agree 0% I disagree 0% No votes Proposal 19 for a legislation No comments • 2019-08-07 • Manuela1537 This law should include... I agree 0% I disagree 0% No votes First Previous 1 You're on page 2 Create a proposal CATEGORIES Open government This portal uses the CONSUL application which is open-source software. For technical assistance visit Participation Decide how to shape the city you want to live in. CONSUL, 2019 | Privacy Policy | Terms and conditions of use | Accessibility"

@javierm javierm self-assigned this Sep 8, 2019
@javierm javierm force-pushed the reduce_proposals_in_pagination branch 2 times, most recently from cc53d73 to ab17282 Compare September 9, 2019 02:56
@javierm javierm changed the base branch from capybara_webmock to master September 10, 2019 13:01
We're getting a failure on Travis in one of these tests. Debugging shows
the AJAX request rendering the first page (after clicking the "Previous"
link) takes too long and sometimes it exceeds Capybara's timeout.

After running the test thousands of times, the only way I've found to
clearly reduce the number of times the test fails is to reduce the
number of records shown on the first page. Other experiments, like
adding an `includes(:author)` to the query getting the proposals in the
controller, or adding `author: user` to the `create_list` part of the
test (so only one author needs to be fetched when rendering the
proposals) show inconsistent results regarding performance.

Note we still need at least 10 proposals for the test for several users,
to guarantee two users will never get the same records during the test
(or at least the probability they get the same records is one in
millions).
@javierm javierm force-pushed the reduce_proposals_in_pagination branch from ab17282 to 1c071b5 Compare September 10, 2019 13:01
@javierm javierm merged commit 233e65f into master Sep 10, 2019
@javierm javierm deleted the reduce_proposals_in_pagination branch September 10, 2019 13:58
@javierm javierm added this to Release 1.1.0 in Roadmap Sep 10, 2019
smarques pushed a commit to venetochevogliamo/consul that referenced this pull request Apr 29, 2020
…in_pagination

Reduce the number of proposals in pagination spec
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Roadmap
  
Release 1.1.0
Development

Successfully merging this pull request may close these issues.

None yet

1 participant