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.

Sign up for GitHub

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

Jump to bottom

Consider filtering out generated report entries from incidents and incident reports endpoints #1375

Closed
srabraham opened this issue Nov 5, 2024 · 1 comment
Closed

Consider filtering out generated report entries from incidents and incident reports endpoints #1375

srabraham opened this issue Nov 5, 2024 · 1 comment
Assignees
@srabraham

Comments

@srabraham
Copy link
Member

For prod data, a large majority of incidents' and incident reports' report entries are system-generated (e.g. "Abraham added incident type Junk"). We should consider filtering out those entries from our calls to incidents and incident reports, to make everything faster and reduce the amount of data needed to be stored in the web clients.
@srabraham srabraham self-assigned this Nov 5, 2024
srabraham added a commit that referenced this issue Nov 12, 2024
@srabraham
exclude system entries from calls for all incidents and incident reports
b799832 
This does not change the default behavior of the APIs, as this adds a
new query param that must be set to "true" to get the new behavior.

This change should make the incidents page load noticeably faster,
since we'll put less pressure on the server, and the data retrieval
will drop from around 4 MB to 2 MB. Additionally, the search should
be faster, because we'll be searching over much less unnecessary text.

#1375
@srabraham srabraham mentioned this issue Nov 12, 2024
Merged
srabraham added a commit that referenced this issue Nov 12, 2024
@srabraham
exclude system entries from calls for all incidents and incident repo…
01f8d45 
…rts (#1396)

This does not change the default behavior of the APIs, as this adds a
new query param that must be set to "true" to get the new behavior.

This change should make the incidents page load noticeably faster,
since we'll put less pressure on the server, and the data retrieval
will drop from around 4 MB to 2 MB. Additionally, the search should
be faster, because we'll be searching over much less unnecessary text.

#1375
@srabraham
Copy link
Member Author

This brought the staging 2023 incidents table API call down from 4 seconds to about 2 seconds, which is pretty sweet. Between this change and #1324, I've taken that down from 10 seconds to 2 seconds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@srabraham srabraham

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@srabraham