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

Initial loading is still slow despite including data for trips-table from the last 7 days only #100

Open
achasmita opened this issue Feb 7, 2024 · 6 comments

Comments

@achasmita
Copy link
Contributor

achasmita commented Feb 7, 2024

  • I checked on staging and noticed that it is taking time while loading data page.
  • The data page initially load uuid-table
    • In uuid table only data for update_ts, user_id, user_token are stored initially
    • Other columns are loaded only after user select the respective tab or initially data-page
      • And it calls add_user_stats function only after that which provides data for all the columns of table.
      • This function is used to get all the other data for column like total_tips, labeled_trips, first_trip,........
    • As the other columns for trips table are not stored and loaded only when UUIDs tab is selected, it is consuming time while we switch back to UUIDs tab from other tabs.

Here are the possible solutions:

  • Reducing the data on uuid-table, maybe display 20-25 data at the begining and allow user to load more data.
  • Reduce data and load all columns initially and store it, instead of calling it when tab is selected. So that it will not consume much time while switching between tabs.
@achasmita
Copy link
Contributor Author

@shankari any suggestion?

@shankari
Copy link
Contributor

  • It is not just loading the data table that is slow. Even just logging in to the dashboard with the summary page is slow.
  • I don't think that those are the only two solutions. "As the other columns for trips table are not stored and loaded only when UUIDs tab is selected," a simple fix would be to store the other columns. Note that this should be "other columns for the UUID table".

Can you also discuss this with @JGreenlee and come up with a solution jointly?

@JGreenlee
Copy link
Contributor

Since I was testing the trip time page, which is outdated and doesn't have the 1 week filter, it was of course slow. I've yet to try the staging dataset on a more up-to-date branch.
Let me try doing that and see if I can get a better understanding of the slowness

@JGreenlee
Copy link
Contributor

JGreenlee commented Feb 22, 2024

  • It is not just loading the data table that is slow. Even just logging in to the dashboard with the summary page is slow.

This isn't what I observed on master with staging data. The "Overview" page consistently loads in about 3 seconds for me.
The dump that I am using has about 40 users and 3000 trips. Might that not be enough to notice the slowness?

The "Data" page takes 20 seconds to load.

@JGreenlee
Copy link
Contributor

I've just realized that was with "Exclude test users" enabled.

Without test users excluded, there are about twice as many users and trips. The "Data" page takes about twice as long to load. The "Overview" page still takes about 3 seconds.

@shankari
Copy link
Contributor

@JGreenlee and @achasmita you should retry on the staging server. I just retried and it took ~ 45 seconds to load the overview page. Note that in staging/production, we don't use a DB that runs on the same host as the code, and DB accesses are significantly slower.

@JGreenlee you should have access to the staging logs through AWS cloudwatch. @achasmita should have a staging login.
We can also add a cognito login for Jack on staging, please let me know if you need help for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Issues being worked on
Development

No branches or pull requests

3 participants