I need some help with this 503 error I seem to be getting on the xo5 free hosting server. what I'm trying to do is get a list from a database for my unity game could anyone tell me if it could be my code or the server itself is being slow? any info would be appreciated.
503 Backend fetch failed
- Thread starter awesom85
- Start date
- Status
- Messages
- 3,295
- Reaction score
- 227
- Points
- 63
You can't delete, and there's really no need to.
And you should probably be aware that unless you've done something major (like changed an algorithm from O(n²) to O(n) or O(log n)), you may still run into the occasional 503 when the server is busy and you need to wait for your database request in the queue. If it's something that doesn't need to be tremendously real-time-like, you might find it a better idea to pre-assemble the data as a static resource (like a JSON file, XML (eeew) or an HTML segment) with a cron. There's still a 30-second limit, but it starts when resources are available rather than on user demand (the cron schedule is more of a suggestion than an order if you look at the time close enough), so there's a greater chance of the request completing - and you always have the fallback of the previously-created (if somewhat stale) resource, which may be good enough. Just a suggestion; I don't know how "live" you data need to be.
And you should probably be aware that unless you've done something major (like changed an algorithm from O(n²) to O(n) or O(log n)), you may still run into the occasional 503 when the server is busy and you need to wait for your database request in the queue. If it's something that doesn't need to be tremendously real-time-like, you might find it a better idea to pre-assemble the data as a static resource (like a JSON file, XML (eeew) or an HTML segment) with a cron. There's still a 30-second limit, but it starts when resources are available rather than on user demand (the cron schedule is more of a suggestion than an order if you look at the time close enough), so there's a greater chance of the request completing - and you always have the fallback of the previously-created (if somewhat stale) resource, which may be good enough. Just a suggestion; I don't know how "live" you data need to be.
- Status