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

BUG: Investigate slow page loads #185

Open
briri opened this issue Jan 28, 2025 · 1 comment
Open

BUG: Investigate slow page loads #185

briri opened this issue Jan 28, 2025 · 1 comment

Comments

@briri
Copy link
Collaborator

briri commented Jan 28, 2025

Some of the pages currently load slowly. We need to investigate to see if we can improve the performance.

  • Only run in production mode on the deployed servers (so it's not compiling on the fly or watching files)
  • Check GraphQL query response times
  • Examine queries in detail and more indexing on the DB
@briri
Copy link
Collaborator Author

briri commented Feb 12, 2025

I was able to experience some of the slowness and observe what is going on. Here are my initial thoughts:

Frontend:

  • Examine GraphQL queries for efficiency. I noticed in the backend a lot of generating Error: Queue limit reached for the MySQL queries. I think in some cases we are fetching things we don't need. When a chained resolver is requested, it fires off additional queries. For example:
    • /template page is fetching Templates along with all of their sections and questions but only displays Template info (remove the section and questions if they're not getting displayed anywhere)
    • /template/create (after name entry) is fetching all Templates along with their sections and questions

Backend:

  • Consider creating new schema types for complex queries (e.g. ProjectSearch) which is tailored specifically to execute a single query and return everything as a single object (e.g. projectName, projectAbstract, researchOutputCount, etc.)
  • Consider updating the MySQLModel so that it stashes queries into the cache for a period of time. This could work something like:
    • When we execute a "SELECT" query like SELECT * FROM templates WHERE id = 123 we could add a new cache key like mysql:templates:123 with the JSON results as a payload. We would need to decide on a TTL
    • The MySQLModel could be configured to check the cache first before running the query
    • When we execute an "UPDATE" like UPDATE templates SET field = 'value' WHERE id = 123 we could just ensure that we call the appropriate "FindByX" function so that it overwrites the results of the cache key mysql:templates:123
    • When we execute a "DELETE" like DELETE FROM templates WHERE id = 123 we could invalidate/expire the cache key for mysql:templates:123

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

No branches or pull requests

1 participant