Hi everyone,
Just to inform you, we've added caching to API requests to try to reduce server load. As thousands of people use community made software / extensions which needlessly request many selections simultaneously every 5 seconds 24/7 this was beginning to have some impact. The API was responsible for upwards of 75% load!
For example, I believe DocTorn is doing this every 5 seconds for most players:
basic,bars,icons,money,notifications,cooldowns,travel,education,messages,events,timestamp
That's mental.
We could combat this by changing 'requests amount' to each individual selection used in one request, or lowering the amount of API requests allowed, but I think this is the least disruptive.
Caching is currently set at 30 seconds, or 600 seconds for User > Networth. So you can ping the API every 5 seconds, but you'll only get new information every 30 seconds.
However I'm happy to announce that we're going to look into implementing sockets into the API to handle instant notifications (exactly the same as the mobile apps do).
Thanks.
Once live sockets are available via the API, I expect we'll change default caching to 60 seconds (or 59 second to avoid overlaps). Which should keep Torn really stable and give developers a nice simple rule to work around.
Good news! That will make many things easier and also should help to reduce the load on Torn further.
I just recently started working with sockets and they are amazing.
I have a question regarding the caching though. Is it going to affect the live sockets too or just the regular API calls?
Is it possible to exempt the chain count from this?
Well you can't really cache web sockets per se...
I assume Ched means the regular requests will be cached and web sockets will not be since it's a pub/sub transmission.
Overall though, good news. I think DocTorn defaults should be changed, even for chain counters there is nothing stopping internal timers ticking in the browser for the countdown and do checks every 30 seconds instead.
Crazy thought Ched, would using Cloudflare Workers help at all? Refactor time is probably the big blocker to this, but assuming 100,000,000 requests per month, that's just $45/month to run which is waaayyyy more economical. That being said it only handles the HTTP load and not the DB, and their worker KV store is another $0.50 per million reads and $0.50/GB storage. But given most are probably the same core group generating most load, it could offset quite a bit compared to say Lambda or AWS API Gateway.
Agreed. Cache everything else, but the chain count is useless with a 30 second cache. Or add a chain counter with an alarm as part of Torn, and the third-party solution wouldn't be necessary.
I think it's better to keep 30 second cache: Get requests are intended for history fetching imo, not live polls. The proposed sockets sounds more promising for that kind of event. But until then, here is a userscript I quickly wrote up just incase API fell again:
https://github.com/Echoblast53/echoblast53-torn-userscripts/raw/master/Userscripts/echo_vchain.user.jsI don't feel like distributing it because I haven't worked on making a friendly interface to change values. But the script basically piggybacks on Torn's calls and
tells you when it has reached 1 min left (tab to faction page must be open). This should help, since people leave a page open to watch the bar anyways.
thanks. code looks straight forward, I can always edit the time directly if I want a different one.
Maybe consider using webhooks instead of sockets. With webhooks, users get to registerer a url on which they want to receive a notification when something happens, for example whenever their energy changes.
These are lightweight and easy to use and, in my opinion, a better fit to work in conjunction with the API than websockets.
I'd disagree, websockets are far more scalable than a webhook, and sockets work far better when users are involved who don't have their own endpoints on which to receive requests.