Support

Akeeba Backup for Joomla!

#34720 Akeeba backup 8.0.2 slow and not saving configuration changes

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 Saturday, 03 April 2021 20:17 CDT

prh47bridge

Today I upgraded Akeeba on my Joomla site. The first attempt to upgrade to 8.0.1 (from 7.something) failed with an FOF error. I then upgraded Joomla from 3.9.24 to 3.9.25 and tried again. This time Joomla refused to download the Akeeba update with a 403 error. I therefore downloaded the zip manually and installed it. The installation worked. However, if I went to the Akeeba control panel things were very slow and my website became unresponsive for a while.

Having discovered that 8.0.2 had been released and seen some of the problem tickets for 8.0.1, I updated to 8.0.2 by downloading and installing the zip file. I then waited a while and installed it again. The current status is:

  • if I go to the control panel and click "Configuration", it takes a very long time for the configuration to appear, during which time my website is unresponsive
  • If it then change and save the configuration, Akeeba claims that the configuration has been saved (instantly if I stay on the configuration page, after a long delay if I close the configuration). However, the configuration is unchanged, so either it isn't picking up my changes or it isn't saving them. If it makes any difference, I am attempting to change the output directory so that I am no longer using the default
  • I haven't tested exhaustively but some other operations such as attempting to view a log file are similarly extremely slow

Any ideas on how I can fix this?

 

nicholas
Akeeba Staff
Manager

It sounds like you have a problem with your server.

Akeeba Backup 8 no longer loads JavaScript blocking, it loads it deferred. This means that your browser waits until the DOM is loaded before loading and running the JavaScript. On a decent server this is actually faster than the previous blocking loading of JavaScript. On a SLOW server, however, the page may take a very long time to load, especially if it has plenty of blocking JavaScript loading due to third party plugins. This means that every page of our component that uses a lot of JS (config wizard, configuration, backup etc) will appear to take a long time to load.

Regarding saving the configuration it does save. It posts a form like it's been doing since 2009. The way this page works hasn't changed in 12 years. If it returns instantly the problem is that something doesn't quite run correctly on your browser. Try clearing the browser cache.

The log page hasn't changed at all. It has always been slow since it asks the browser to render a massive document.

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!

prh47bridge

I've largely fixed the speed issue by increasing the number of children FPM can spawn. It seems that Akeeba spawns way more child processes when displaying the configuration than any of the other extensions I've got. Note that the issue is not, as far as I can see, anything to do with blocking JS. Looking in the browser debug console, when I have FPM set to a maximum of 5 child processes the request to /administrator/index.php?option=com_akeeba&view=Configuration takes over one minute to respond. Subsequent requests for JS, CSS, etc. all complete in just a few milliseconds.

This also appears to have fixed saving the configuration. Testing I did before increasing the number of child processes showed that I could change the log level and that would save correctly but changes to the output directory were ignored. All very strange.

 

nicholas
Akeeba Staff
Manager

The Configuration page only spawns one process, the one rendering the Joomla request. Everything else happens client-side, with JavaScript.

The Configuration Wizard also only spawns one process at a time, for the original page load and each AJAX request.

Both pages have worked like that since 2009 and 2012 respectively. The only changes over the years has been the HTML structure the client-side JavaScript code generates since we went from custom CSS to Bootstrap 2 (when Joomla 3.0 was released) to our own custom CSS framework. The other change, made in version 7.0 which was released December 2019, was the removal of jQuery in favour of vanilla JavaScript code.

That said, 5 children per FPM process is low for a live host, especially if you keep the process pool small. The your site gets even moderately busy (we're talking about one request every 3 to 5 seconds) your PHP FPM process pool will be exhausted. Your web server will be waiting on PHP-FPM to free up a thread and handle the request. That's why everything is slow.

What you need to do is check if you have too many long running PHP processes. This would indicate that another extension is probably entering an infinite loop, meaning that thread is engaged until the PHP timeout kicks in. Do it a few times, combine with a small pool and you have the slow server syndrome. Another possibility would be a bot crawling / attacking your site BUT increasing the pool size would probably not help; the bot traffic would use up all resources. Well, at least the latter is something you can easily look for in the logs.

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!