Support

Akeeba Backup for Joomla!

#28448 JPA file extraction speed

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 on Sunday, 15 October 2017 17:17 CDT

hollai
Please look at the bottom of this page (under Support Policy Summary) for our support policy summary, containing important information regarding our working hours and our support policy. Thank you!

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.

Description of my issue:
On my server (dedicated SSD), when I extract a 500 MB JPA backup file, it takes more than 20 minutes.

If the same backup file was created by the Akeeba Backup extension in Zip format, the backup file is 3 MB larger than the JPA, but it takes only about 15 seconds to extract the given Zip file.

Is it normal that the JPA file extracts so much slower?
If not, could you give me some pointers to what I may need to check on my server in order to speed up the JPA extraction?

nicholas
Akeeba Staff
Manager
The file extension is completely irrelevant. In fact, the extraction code is common by a good 75% between JPA and ZIP. Both are simple archive formats holding unencrypted, GZipped data. Also, this kind of speed difference cannot be reproduced on any of our test and live systems, nor in the thousands of sites we have worked on over the years while helping clients. Simply put, JPA is just "ZIP light". It is the same format minus all the optional extensions, the central directory at the end of the file (itself a relic of the days where ZIP files would span several physical disks) and file checksums (because PHP is pretty bad at calculating them for large files without crashing the server). Compressing to JPA is marginally faster than ZIP, extracting from either is the same speed within statistical significance.

A speed difference of that magnitude would have only made borderline sense if you were comparing JPS (encrypted data) to ZIP or JPA (unencrypted data). The JPS format stores everything encrypted, including file metadata, in up to 64K packets. If your server uses an older processor which doesn't have AES functions at the hardware level (or PHP was compiled without the optimization that makes use of said functions) the extraction should be substantially slower. Still, 20 minutes is way too much. Something like 3' would be more like it.

The other factors that can have this orders of magnitude effect on the extraction speed is the operating system and the way the storage is attached to the computer. Windows is stupidly slower than Linux, macOS and pretty much all other UNIX-derived systems. This comes down to the inefficient way the operating system handles data transfer to the disk and the effective lack of usable disk caching. The way the storage is attached can be a bottleneck, too. An SSD connected over SATA III can reach full speed (theoretical SATA III maximum: 600M/sec; typical server-grade SSD speed: 550M/sec). An SSD connected over fiber optic may reach full speed depending on network conditions. An SSD connected through NFS over regular Gigabit Ethernet will suck as bad as a regular HDD.

Then there other factors at play which could limit throughput. Do you have enough free RAM for a healthy amount of disk cache?Ideally you would have a disk cache that's as big as the amount of data being extracted that the OS doesn't have the time to write back to the SSD while the decompression (non-file-I/O) operation takes place. Also, is there an antivirus or other daemon monitoring the file contents? That could have an orders of magnitude impact on the extraction speed.

If you consistently observe an orders of magnitude difference when accessing JPA files you should contact your host. Most likely they are running some kind of antivirus or other file monitoring daemon which puts a lock on the file, preventing PHP from being able to read from it. It wouldn't even be in my top 20 of stupid things I've seen hosts do.

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!

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

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!