It still takes a long time to load into the game about gg-struggle HOT 20 OPEN

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

from gg-struggle.

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?

from gg-struggle.

from gg-struggle.

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

from gg-struggle.

same issue here too any idea how to fix it?

from gg-struggle.

from gg-struggle.

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.

from gg-struggle.

from gg-struggle.

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

from gg-struggle.

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 :/

from gg-struggle.

from gg-struggle.

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

from gg-struggle.

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

from gg-struggle.

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

from gg-struggle.

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.

from gg-struggle.

from gg-struggle.

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!

from gg-struggle.

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?

from gg-struggle.

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?)

from gg-struggle.

@cybermelons do you have any updates?

from gg-struggle.