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

Improve Sync To User performance (batch 2) #1897

Merged
merged 13 commits into from
Dec 23, 2020
Merged

Conversation

kitallis
Copy link
Contributor

@kitallis kitallis commented Dec 17, 2020

Story card: ch2086

Because

Whilst perf-testing block-syncs, we discovered various inefficencies in our sync (GET) code-paths that get exacerbated when many users re-sync at the same time.

A full list of improvements and the rationale is here.

This addresses

This improves how the overall query for fetching the records that are required to syncing are queried. Making some structural changes to construction of the overall query avoids making inefficient sub-selects.

@harimohanraj89 harimohanraj89 temporarily deployed to simple-review-pr-1897 December 17, 2020 10:48 Inactive
@kitallis kitallis temporarily deployed to simple-review-pr-1897 December 17, 2020 12:58 Inactive
@kitallis kitallis temporarily deployed to simple-review-pr-1897 December 17, 2020 13:16 Inactive
@kitallis kitallis temporarily deployed to simple-review-pr-1897 December 17, 2020 13:32 Inactive
@kitallis kitallis temporarily deployed to simple-review-pr-1897 December 17, 2020 13:52 Inactive
@kitallis kitallis temporarily deployed to simple-review-pr-1897 December 17, 2020 13:54 Inactive
@kitallis kitallis temporarily deployed to simple-review-pr-1897 December 17, 2020 14:03 Inactive
@prabhanshuguptagit prabhanshuguptagit temporarily deployed to simple-review-pr-1897 December 17, 2020 15:58 Inactive
def records_to_sync
current_facility_records + other_facility_records
def model
controller_name.classify.constantize.for_sync
Copy link
Contributor

@rsanheim rsanheim Dec 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I understand why you are returning a AR scope here instead of the actual model, but its a confusing mismatch with the name and conventions around something named model. Maybe rename the method to something like scope to better represent that its the base scope for other methods to build off of? Or maybe region_scope, sync_scope, default_sync_scope ?

Copy link
Contributor Author

@kitallis kitallis Dec 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I wasn't happy with continuing to calling it model. We'd removed model earlier because I disliked its hanging presence with invisible meanings. But I think sync_scope makes sense 👍🏼

@kitallis kitallis temporarily deployed to simple-review-pr-1897 December 18, 2020 06:07 Inactive
@kitallis kitallis temporarily deployed to simple-review-pr-1897 December 18, 2020 07:10 Inactive
@prabhanshuguptagit prabhanshuguptagit marked this pull request as ready for review December 18, 2020 14:34
Copy link
Contributor

@harimohanraj89 harimohanraj89 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple questions/suggestions from me.

scope :syncable_to_region, ->(region) {
with_discarded.where(patient: Patient.syncable_to_region(region))
}
scope :for_sync, -> { with_discarded }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a couple tiny tests for this scope across these models?


def syncable_patients
registered_patients.with_discarded
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a bit dissonant? "Syncable" in general means you are registered in, assigned to, or plan to visit. We're using a simplified definition here because it doesn't really matter when used for facility prioritization. However, does this set us up to do things like facility-level sync incorrectly?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To address the dissonance, I suspect we'd either:

  • update the query here to include all three clauses - This doesn't seem correct because it doesn't maintain feature parity in the sync API, and is also less performant probably
  • update the name of this method? - Something along the lines of prioritized_patients or something? Making it clear that this boundary is not a facility-level sync boundary, but a looser boundary within another block-or-FG-level sync?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

prioritized_patients works I think 👍🏼

region_records
.where(patient: prioritized_patients)
model_sync_scope
.where(patient: current_facility.syncable_patients.pluck(:id))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would a couple semantic methods help with readability?

def current_facility_patient_ids
  @current_facility_patient_ids ||= current_facility.syncable_patients.pluck(:id)
end

def other_facility_patient_ids
  @other_facility_patient_ids ||= current_sync_region.syncable_patients.pluck(:id) - current_facility_patient_ids
end

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They might, I can play around with this. But our general approach was to reduce the number of methods in this mixin. Every method that we add, is an opportunity for someone to override it in some random place in some controller that inherits from it. The thinner this mixin is in terms of pure method volume, the cleaner the internal API is.

I'll take a shot at this and see if it helps anyway. Will respond back here.

app/models/region.rb Show resolved Hide resolved
@prabhanshuguptagit prabhanshuguptagit temporarily deployed to simple-review-pr-1897 December 22, 2020 14:35 Inactive
@prabhanshuguptagit prabhanshuguptagit temporarily deployed to simple-review-pr-1897 December 23, 2020 05:57 Inactive
@prabhanshuguptagit prabhanshuguptagit temporarily deployed to simple-review-pr-1897 December 23, 2020 09:41 Inactive
@prabhanshuguptagit prabhanshuguptagit temporarily deployed to simple-review-pr-1897 December 23, 2020 09:43 Inactive
@prabhanshuguptagit prabhanshuguptagit temporarily deployed to simple-review-pr-1897 December 23, 2020 10:05 Inactive
@prabhanshuguptagit prabhanshuguptagit temporarily deployed to simple-review-pr-1897 December 23, 2020 10:22 Inactive
Copy link
Contributor

@harimohanraj89 harimohanraj89 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lookin' slick ✨

@prabhanshuguptagit prabhanshuguptagit temporarily deployed to simple-review-pr-1897 December 23, 2020 12:18 Inactive
@prabhanshuguptagit prabhanshuguptagit temporarily deployed to simple-review-pr-1897 December 23, 2020 12:33 Inactive
@prabhanshuguptagit prabhanshuguptagit merged commit d78d0ca into master Dec 23, 2020
@prabhanshuguptagit prabhanshuguptagit deleted the sync-perf-2 branch December 23, 2020 13:12
kitallis added a commit that referenced this pull request Dec 24, 2020
kitallis added a commit that referenced this pull request Dec 24, 2020
kitallis added a commit that referenced this pull request Dec 24, 2020
* Revert "Improve Sync To User performance (batch 3) (#1898)"

This reverts commit 8ff7ba1.

* Revert "Improve Sync To User performance (batch 2) (#1897)"

This reverts commit d78d0ca.

* Add the old sync indexes back
kitallis pushed a commit that referenced this pull request Dec 30, 2020
We discovered that the perf improvements for block level sync tend to slow down FG syncing. We reverted the improvements (#1920) to unblock deploys while a fix was figured out.

This combines the reverted perf improvements (#1898 and #1897) and fixes them to be FG compatible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants