Sorry for that downtime – I should have posted here sooner. SOTA has apparently gotten so popular, that the pure volume of spots brought the SOTAwatch server to its knees.
In SOTA Goat, when loading the Spots tab for the first time, it was requesting all spots from the past 24 hours. Unfortunately, the SOTAwatch servers could not respond with all those spots within an interval of 30 seconds, causing a timeout and a 500 HTTP response from the server.
The fix on my end was to simply change that API to request the latest 200 spots, instead, which makes the response much faster. Unfortunately, my server had fallen to neglect over the past couple years of dutiful service, so I could not nimbly deploy a fix. I had to perform major updates to the application and its dependencies to get it deployed again.
I finally finished pushing through that, so it should be nice and snappy now! Please let me know directly if you see any issues resulting from these updates.
Also, were push notifications totally busted, too?? They should also be working FB now.
After working with several high volume users to reduce their impact on the API, and performing some maintenance on the underlying database, load is back down to normal. It would appear the high load placed the database under memory pressure due to its larger indexes, which gradually degraded performance until at peaks requests to the API would timeout.
I’d guess most chasers (at least while actively chasing) are unlikely to need spots older than an hour or so? Might it be worth making the SOTAwatch setting for any longer requests relatively short-lived? Someone may have a need to see all the spots from the last week to check something out, but it’s easy to forget to set the limit back to something sane…
I have a better solution coming in a soon-to-happen update of SOTAWatch (SOTAWatch4?), but I’ll leave the technical details out for now as I haven’t quite finalised the plan.
The bigger issue is occasional random scripts getting the last two hours of spots every 10 seconds. There’s a lot of redundant data being consumed right there… Rate limiting on the way.
Or maybe caching? Since folks typically request only the most recent spots, it would make sense to cache the most recent spots in-memory for quick retrieval.
