524 Timeout - AWS t3.xlarge server with 4 vcpu 16 Memero (GIB)

[email2]

I am using AWS t3.xlarge server with 4 vcpu 16 Memero (GIB), with only one cron running, I am having an Error 524 timeout issue every time when I restore the database.

May I know what causes the issue?

Please advice.

[cherryjimbo]

I’d recommend reviewing the following:

Community Tip - Fixing Error 524: A timeout occurred

Error Try the suggestions in this Community Tip to help you fix Error 524: A timeout occurred. Background Error 524 error indicates that Cloudflare made a successful TCP connection to the origin web server, but the origin did not reply with an HTTP response before the connection timed out. Typically, Cloudflare waits 100 seconds for an HTTP response. If the origin doesn’t respond in that time, Cloudflare closes the connection and you’ll see “Error 524: A timeout occurred”. [PRO UP SELL] Qui…

This is almost certainly an issue at your origin. Restoring a database should probably be a command line thing you run, and not a web request.

[email2]

Thank you for your reply. I have tested it. For the data restoration that is less than 100 seconds, I can run it without any issue, however for the restoration that exceeded 100 seconds, it will end with error 524 regardless of the timeout setting of my server, I understand that 100 seconds is Cloudfront standard and I have gone through the documentation, it seems I have an issue with the #4 as follow, would you please provide some details how do I implement that?

I may have to go without Cloudflare because of this issue.

4. If you need to have scripts that run for longer than around 100 seconds without returning any data to the browser, you can’t run these through Cloudflare. There are a couple of options: Run the scripts via a grey-clouded subdomain or change the script so that it kicks off a long-running background process and quickly returns a status which the browser can poll until the background process has completed, at which point the full response can be returned. This is the way most people do this type of action as keeping HTTP connections open for a long time is unreliable and can be very taxing also.

[KianNH]

@email2

change the script so that it kicks off a long-running background process and quickly returns a status which the browser can poll until the background process has completed, at which point the full response can be returned

As it says, having a long standing operation in a single request is a bad design decision.

You should instantly return a status, i.e to say that starting the operation was successful and then have a page where you can continuously poll for the progress of the aforementioned operation.

As an example from REST API Best Practices — Decouple Long-running Tasks from HTTP Request Processing | by Shawn Shi | Geek Culture | Medium :

This is bad since we’re waiting for the operation to complete before returning a response.

This is good - we get acknowledgement of our request and then we can continuously poll to get the operation status.