Closed cassolv closed 3 years ago
rafaelgomesxyz
commented
4 years ago It's actually always just one request to the /user/username page to get the user's CV, so the number of ongoing giveaways a user has is irrelevant.
And are you positive that it does so on every page load? Because it should only do it when the user's level changes.
cassolv
commented
4 years ago Yeah, it was making one request on every load (or at least on more than 90% of them, during my short test). Within a couple of minutes, I made like twenty-ish requests to a handful of different pages and I had a comparable of requests to that page in the log. When I turned it off, those requests stopped happening, and when I turned it back on, they returned, so I'm pretty sure that this feature is related to them in some capacity (if not by directly making the requests, than possibly via interference with something else?). For now, I'm keeping it off altogether.
Also, if it should only do it on level changes, the rationale for #1663 becomes kind of moot, so as far as I'm concerned that becomes unnecessary; your call on whether it remains relevant as a feature on its own right.
rafaelgomesxyz
commented
3 years ago Oh, I found the error.
I have noticed that the 1.20 Level Progress Visualizer feature sends a request to the user's page (e.g. steamgifts.com/user/yourusername) on, at least as far as I can tell, every page load. From what I understand, it is doing it to update the estimated level, in which case I expect that, if the user has e.g. 180 ongoing giveaways (say, for instance, when they're running a lengthy train), it will load up to page 8, thereby producing eight requests. On the assumption that this is indeed happening on every manual page load, if that hypothetical user a mere handful of pages, that feature alone will already hit ESGST's self-imposed per-minute limit. That is less than ideal.
While I can easily appreciate that poking the user page every now and then to update the estimated level can be necessary, doing so on every page load is not. To solve that, I think the estimated level should be cached aggressively and updated only in two circumstances: when the user creates a giveaway and otherwise once in a given time frame; once per hour is probably fine, but I'd even go with once per day.