Support

Akeeba Backup for Joomla!

#19416 Time out during post processing to S3

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
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

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Friday, 07 March 2014 02:22 CST

beemerrider
EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

Dedicated server, quad processor, RAID Array, 8GB RAM, Joomla sites only, around 80 sites, all medium to small sites. Server loads, CPU RAM usage all within acceptable ranges.

When Upgrading from earlier version of Akeeba backup to 3.10.0 or 3.10.1 my backups would no longer post process consistently to Amazon S3, only about 1 in 5 backups would work. The post processing time was running very long, in the 20 to 60+ second range.

While checking all the server settings to make sure nothing had changed I thought it might be a good time to upgrade from 5.3.xx PHP to 5.4.xx PHP. After rebuilding PHP via Apache I am now not having any further issues with backing up any of my sites using the latest version of backup. Just wanted to let you know that incase you come across a similar support ticket.

 Bruce Wilson Formations Design Group, LLC Vancouver, WA USA

nicholas
Akeeba Staff
Manager
I can think of five different reasons why this could happen, but it's not very productive speculating. Please ZIP and attach your Akeeba Backup log file. If you are not sure how to do that please consult our page on requesting support. The fifth bullet point describes how to obtain your log file. Put it in a ZIP file and attach it to your next reply. If the file is over 2Mb please upload it to Dropbox or your site and paste a link here.

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!

beemerrider
I did a lot of testing before talking up anymore of your time. I hope what I have found may be of help. I spoke to soon when I thought the upgrade to PHP may have solved the issues. But I do think some changes that were made to the PHP config at the server level may be the problem. A couple weeks back I was doing an upgrade to JomSocial on a site and it instructed me to up some time limits in PHP and MySQL, so I set the limits to their specs. This was right around the time a lot of my sites started having issues during the post processing to S3. It was also around the time I was updating extensions on several sites, including Admin Tools and Backup. So too many variables to figure out what caused what.

Anyhow I was able to get two of the sites that had consistent problems with time outs during post processing to work. I tried a backup with 3.8/xx and it failed during post processing to either S3 or Dropbox. I then upgraded to 3.10.1 and the same problem. The server response time would rise to around 63 seconds and then I would get a timeout error. I had run the config wizard both times. I then changed the part size form the 2GB the wizard had selected to various sizes down to 20MB with no luck. I have never had issue with this setting in the past three or four years. Finally I tried setting the Execution time bias from 75 to 50 and then both sites I was trying to back up both backed up successfully. I tried with 75 on both sites, both failed, then set them to 50 and both worked. I hope this is the fix.

Question, what is the server response time that is showing during post processing. It used to run between a couple seconds to sometimes as high as 20 seconds. Now after I set the bias time to 50 it seems to run more in this range again instead of the 20 to 60 second time frame. I still see and accessional 59 or 60 second reading, but most are in the 1 to 3 second reading. Attached are the logs for both sites I was experimenting with and also one screen shot. I guess I can only attach one file. So I've zipped three files into the one uploaded file

 Bruce Wilson Formations Design Group, LLC Vancouver, WA USA

nicholas
Akeeba Staff
Manager
OK, this is one of the reasons I was suspecting. You have enabled the multipart upload to Amazon S3 which is dependent on two external factors: the response time from Amazon servers and your PHP timeout. As you can read in the last 3 paragraphs of our troubleshooting instructions some server configurations don't play nively with that and it's advisable to disable it.

Generally speaking, it's best to use small part sizes (around the 10Mb area) when uploading backups to remote storage. The exception is when using the native CLI script (cli/akeeba-backup.php) from a CRON job. In this case you do not have any execution time limits so you can have big parts, up to 2Gb, without any problems.

As for the execution time, it does make sense. What you actually need to do is set:
Minimum execution time: 1 second
Maximum execution time: 14 seconds
Runtime bias: 75%
This is the default and rather conservative setting. Akeeba Backup will work happily until the 10 seconds mark (14 * 0.75 = 10.5 seconds to be exact) and then it will start considering whether it should break the step. If it expects a long operation to take place, such as uploading another part to S3 or Dropbox, it will break the step, preventing the timeout error from occurring. You seem to have a high Maximum execution time which explains why you had to lower the runtime bias a lot to get it working and why this doesn't always happen (the runtime bias is the threshold for considering whether to break the step, not the hard limit to break the step no matter what).

Overall I am very impressed that you did grasp most of the minutiae of configuring the time limits in Akeeba Backup. Most clients throw in the towel much earlier than that and come here asking for a solution :)

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!