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

It still takes a long time to load into the game #21

Open
dermil opened this issue Jul 28, 2021 · 20 comments
Open

It still takes a long time to load into the game #21

dermil opened this issue Jul 28, 2021 · 20 comments

Comments

@dermil
Copy link

dermil commented Jul 28, 2021

Even after the first attempt to get in, it still takes about 4 minutes to get into the game when I close and re-open. Is this necessary to prevent the issues from the last version? I've included a screenshot of what's happening for refs
gg-struggle_M8OTWCnDLC
@RaghavRao
Copy link

Having the same issue, same load times on every start
all.log

@Scott-Lan
Copy link

Same here. faq is somewhat unclear when it says "slow first load".. as in first time you load each launch? or first ever launch with the mod?

@RaghavRao
Copy link

RaghavRao commented Jul 30, 2021 via email

@Scott-Lan
Copy link

thanks for the info, can confirm this as an issue then.

@pheizaut
Copy link

pheizaut commented Aug 1, 2021

same issue here too any idea how to fix it?

@RaghavRao
Copy link

RaghavRao commented Aug 1, 2021 via email

@cybermelons
Copy link
Owner

hey sorry for the late reply. yes, the load times are slower. With the new caching strategy, we sacrifice some speed for the sake of consistency. By sending out every request, the requests initiated on startup change.

To optimize it, it'd take more fine tuning by analyzing each request which can be time-consuming. So I suggest heading on over to https://github.com/optix2000/totsugeki and trying that out, as long as you're aware that it edits memory.

@RaghavRao
Copy link

RaghavRao commented Aug 2, 2021 via email

@cybermelons
Copy link
Owner

cybermelons commented Aug 3, 2021 •
edited

Sure. Take a look at this block: https://github.com/tsaibermelon/gg-struggle/blob/main/server/gg-struggle.js#L102

      // store the response if cache policy says so
      let fetchCallback = this.shouldCache(gameReq.url) ? storeIfExpired : doNothing
      ...
      this.fetchGg(gameReq, fetchCallback)

With this addition in 1.5, we send unconditionally send out the game's request when they were previously dropped on cache-hits, leading to rank updates not registering. During development, I noticed this could change the start-up requests, resulting in a cache-miss to wait for the real server data. But it it doesn't make sense that this change would change the start-up requests if they're cached for a few hours.

It could also be an issue with the reconfigured cache-policy settings. Try editing local.json to change a setting from 5 mins to 3 hours

        "/api/sys/.*": "3 hours",

See if that speeds things up

@DJKero
Copy link

DJKero commented Aug 9, 2021

Sure. Take a look at this block: https://github.com/tsaibermelon/gg-struggle/blob/main/server/gg-struggle.js#L102

      // store the response if cache policy says so
      let fetchCallback = this.shouldCache(gameReq.url) ? storeIfExpired : doNothing
      ...
      this.fetchGg(gameReq, fetchCallback)

With this addition in 1.5, we send unconditionally send out the game's request when they were previously dropped on cache-hits, leading to rank updates not registering. During development, I noticed this could change the start-up requests, resulting in a cache-miss to wait for the real server data. But it it doesn't make sense that this change would change the start-up requests if they're cached for a few hours.

It could also be an issue with the reconfigured cache-policy settings. Try editing local.json to change a setting from 5 mins to 3 hours

        "/api/sys/.*": "3 hours",

See if that speeds things up

I'm having the same issue and changing that line didn't improve the load time :/

@RaghavRao
Copy link

RaghavRao commented Aug 10, 2021 via email

@DJKero
Copy link

DJKero commented Aug 10, 2021 •
edited

Is the cache being used at all?
…
On Mon, Aug 9, 2021, 18:19 DJKero @.**> wrote: Sure. Take a look at this block: https://github.com/tsaibermelon/gg-struggle/blob/main/server/gg-struggle.js#L102 // store the response if cache policy says so let fetchCallback = this.shouldCache(gameReq.url) ? storeIfExpired : doNothing ... this.fetchGg(gameReq, fetchCallback) With this addition in 1.5, we send unconditionally send out the game's request when they were previously dropped on cache-hits, leading to rank updates not registering. During development, I noticed this could change the start-up requests, resulting in a cache-miss to wait for the real server data. But it it doesn't make sense that this change would change the start-up requests if they're cached for a few hours. It could also be an issue with the reconfigured cache-policy settings. Try editing local.json to change a setting from 5 mins to 3 hours "/api/sys/.": "3 hours", See if that speeds things up I'm having the same issue and changing that line didn't improve the load time :/ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUBDU2IYIJRKKI3QQEOUBDT4BH6HANCNFSM5BEKAAGA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

It seems that the api/statistics requests aren't being cached or something else is wrong, I tried by going back to the title screen and entering again and all of them are reporting cache miss.

Second login attempt:
example.log

@RaghavRao
Copy link

Thank you. Yes not a single Hit except one for login... Which means at this point its probably slower to use this than regularly logging on

@RaghavRao
Copy link

I fixed it. I noticed %TEMP%\gg-struggle\dumps had 13000 entries so I deleted everything in the folder. I also deleted the gg-struggle.db file, and ran the uninstaller and reinstalled.
I then set the cache time for /api/statistics/.* to -1:
local-json.txt

Here is the log for attempt 2:
attempt2.log

Here are my guesses:

  1. 13000 entries clogs up JS look up and it misses even though its there (unlikely, no JS experience however)
  2. "hours" isn't being parsed correctly, and a value in seconds is needed (maybe 3600 instead of -1 is better?)
  3. There is a bug in the code for all positive times

@pheizaut
Copy link

Can confirm Raghavs fix made the game launch almost instantly. I would guess that this brings the rank issues back but Im locked at max rank regardless.

@RaghavRao
Copy link

RaghavRao commented Aug 13, 2021 via email •
edited

@DJKero
Copy link

DJKero commented Sep 9, 2021

Sure. Take a look at this block: https://github.com/tsaibermelon/gg-struggle/blob/main/server/gg-struggle.js#L102

      // store the response if cache policy says so
      let fetchCallback = this.shouldCache(gameReq.url) ? storeIfExpired : doNothing
      ...
      this.fetchGg(gameReq, fetchCallback)

With this addition in 1.5, we send unconditionally send out the game's request when they were previously dropped on cache-hits, leading to rank updates not registering. During development, I noticed this could change the start-up requests, resulting in a cache-miss to wait for the real server data. But it it doesn't make sense that this change would change the start-up requests if they're cached for a few hours.

It could also be an issue with the reconfigured cache-policy settings. Try editing local.json to change a setting from 5 mins to 3 hours

        "/api/sys/.*": "3 hours",

See if that speeds things up

I think the issue is here:

https://github.com/cybermelons/gg-struggle/blob/main/server/gg-struggle.js#L94

try negating the conditional, like:

if (**!**this.isItemExpired(ggResp))

Tell me if it works!

@DJKero
Copy link

DJKero commented Sep 9, 2021 •
edited

Sure. Take a look at this block: https://github.com/tsaibermelon/gg-struggle/blob/main/server/gg-struggle.js#L102

      // store the response if cache policy says so
      let fetchCallback = this.shouldCache(gameReq.url) ? storeIfExpired : doNothing
      ...
      this.fetchGg(gameReq, fetchCallback)

With this addition in 1.5, we send unconditionally send out the game's request when they were previously dropped on cache-hits, leading to rank updates not registering. During development, I noticed this could change the start-up requests, resulting in a cache-miss to wait for the real server data. But it it doesn't make sense that this change would change the start-up requests if they're cached for a few hours.
It could also be an issue with the reconfigured cache-policy settings. Try editing local.json to change a setting from 5 mins to 3 hours

        "/api/sys/.*": "3 hours",

See if that speeds things up

I think the issue is here:

https://github.com/cybermelons/gg-struggle/blob/main/server/gg-struggle.js#L94

try negating the conditional, like:

if (**!**this.isItemExpired(ggResp))

Tell me if it works!

Nvm just saw that it's just a node server, I'm trying it out.
Will edit this message when I know if it works.

Edit:
Nope, it doesn't.
How do I enable the debug messages?

@DJKero
Copy link

DJKero commented Sep 9, 2021

I've been toying with this issue, and it seems that the statistics keys aren't consistent between launches (maybe they patched client+server to rotate the keys with time?)

@RaghavRao
Copy link

@cybermelons do you have any updates?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@DJKero @RaghavRao @dermil @pheizaut @Scott-Lan @cybermelons