Support

Akeeba Backup for WordPress

#36813 Invalid AJAX data: (HTML containing script tags)

Posted in ‘Akeeba Backup for WordPress’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

WordPress version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Sunday, 27 March 2022 14:40 CDT

RRO

Hi Overthere,

I've got a site on IONOS webspace. When tryin' to backup I get

Invalid AJAX data: (HTML containing script tags)

Akeeba-BE is telling me "There's a problem, trying to resume" finally failing.

Β 

While the backup is running I noticed that the ZIP-archive is started and when the BE is throwing it's error, Akeeba Backup restarts archiving.The point of failure is mostly around 190MB but not always the same.

May somebody have a look please? This is a restart of ticket #36565.

All the best

Ralf

nicholas
Akeeba Staff
Manager

Go to Akeeba Backup. Select your backup profile. Click on the Configuration button. Scroll down and find the File-tuning area. Set:

- Minimum execution time: 0

- Maximum execution time: 7

- Runtime bias: 75%

Click on Save & Close and start a new backup. If it fails again please ZIP and attach your new log file.

Explanation: Each "Starting Step number" line in your log file indicates the beginning of a new page load (the page load actually starts at the "Kettenrad :: Attempting to load from database" line in steps 2 and above). I see that steps 1 through 7 take between 1 and 4 seconds, they complete just fine. Step number 8 seems to be consistently killed by the server at 9 to 10 seconds. This tells me that your server has an effective time limit of 10 seconds.

But, you will tell me, the log file says that PHP reports a maximum execution time of 50000 (fifty thousand) seconds! Yes, that's not the only timeout. There are two to three more timeouts in play. First, you are using PHP FastCGI, probably through PHP-FPM, which means that there's the PHP-FPM timeout itself. Then there's the Apache timeouts: a timeout for waiting PHP to send data and a timeout for the entire request. Finally, most servers have a maximum CPU usage limit per process; any process using the CPU longer than that is killed.

Given the +/- 1 second kill-off of the backup process I would think it's the latter. Why is that? Because the CPU usage time and the wall clock time are two different things. If you use 100% of the CPU they will be identical. Since you never use 100% of the CPU (plus the way of how the Linux kernel counts CPU usage time) you usually get ~10% to 30% more wall clock time than CPU time (meaning your average CPU usage is between 70% and 90%) in most cases.

The solution to that is having the backup run for decidedly less time than that. So why set it to a maximum of 7 seconds instead of 10? Because the smallest unit of processing is a file as big as the Big File Threshold option in Akeeba Backup, 1Mb by default, which might take a second or so to be processed. I also want to add some "buffer" so as not to run way to close to the timeout limit which would result in the backup failing again.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

RRO

Hello Nicholas,

thx again for your great explanation and insight into Akeeba Backups inner workings.

I was fooled by the 50000, and after your reply questioned this to the hoster IONOS.

Thx to their multilevel-support I only could get to someone with low clearance who told me that he can't see anything else than the 50000 but there may be restrictions in place for the server-instance of my clients webspace (that's what I understood), and that they solved such issues for other clients by upgrading their contracts.

Only than I learned while they have not renamed their product since my client booked it in 2009 they nonetheless changed the technology behind the product without upgrading the older contracts. So there are two products "2009" and "2022" both named "Essential" which seem to be the same but actually are not.

He than upgraded "Essential (2009)" to "Essential (2022)" and problem seems to be solved or less obvious. I'll watch it and report back in case I need to resolve to your solution above.

Have a great weekend and thx for the great products and support over all the years! :-)

Ralf

nicholas
Akeeba Staff
Manager

I made the ticket public per the client's wish. Thank you very much for letting us have this information public!

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!