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

Performance - General #314

Open
merforga opened this issue Jun 25, 2018 · 0 comments
Open

Performance - General #314

merforga opened this issue Jun 25, 2018 · 0 comments

Comments

@merforga
Copy link
Member

tl;dr We're sending a lot of data we don't need to.

dont load all leaderboards data on initial page request

  1. i will never look at all the weekly speed clears except i select them
    you can reduce the data here from 150kb to 16 kb in the json just by stripping the weeks
  2. i dont need all the buff data for every encounter here so why do you send it in the leaderboards? i cannot even look at it so please strip it

any stats page
you seem to send the data for every percentil instead of just the fixed values we can select, thats overhead again
fun fact: 1 percentile of power weaver on all bosses this era is 2292 cleave dps, so dont be hard on your group, other groups managed to kill it with worse 😛

profile page
we write the year 2025: the profile page takes about 10min to load
i myself dont raid that much, the profile.json takes 4.1mB and 41s seconds to load. 28s of that is waiting, so i guess it takes half a minute to compile the data on the server for me, the download itself takes 13s
at first: remove eras pls! you are loading every damn era. i only want the one that i have selected
second: please load only the boss i have selected
again: buffs that i dont see

i played 4 different elites this era, on 19 different encounter types. (CMs and fracs and stuff are all extra) that alone is almost 80 times the whole dataset of everyone like we can see on the globals page
multiply that by 7 eras and you have the profile page. imagine me playing every elite...
alone with the first 2 changes we could go from 4.1mB to 30kB

30s wait is also very long. idk what on your server caused this but with more restrictive queries this should rocket down to milliseconds...

this data is great for having in an api but not on the normal user frontend

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants