Looks like I got that wrong (not entirely unexpectedly…)
Any GET request that is proxied through the backend will return Backend not available when Compute is down. A simple test of such would be https://compute.rhino3d.com/version
If you are running your own apps, I highly recommend setting up your own instance of compute. Our server is really meant only as a prototype that people can use as a starting point example in creating their own custom compute servers.
Thanks for letting me know, @martinkretz! It’s back up now. I’m trying to figure out why it been going down a lot over the past week. The /grasshopper endpoint has been seeing a lot of use and I wonder if there’s still a memory leak there…
I’ve moved the service from EC2 to EKS and, aside from a mistake which caused the most recent outage, it’ll be a lot easier to manage now.
Posting here is perfect - it’s the quickest way to alert me and let other users know that they’re not the only ones having issues.
Thanks for the info. In our testing previously I do think that we also hit that memory leak since multiple working requests with the same data would suddenly stop working after 10 requests, and then just keep failing.
And on that note, it seems that it is down right now.
@martinkretz Ah, this was an unrelated blunder of mine to do with the handling of content-type headers in the proxy that we put in front of compute to handle authentication. It wasn’t an issue with compute itself. Should be fixed now!