Support

Admin Tools

#43504 Admin Tools Pro 7.9.4 – Very slow file scanning

Posted in ‘Admin Tools for Joomla!’
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
5.4.10
PHP version
8.2
Admin Tools version
7.9.4 Pro

Latest post by nicholas on Tuesday, 10 November 2026 15:27 CST

Monday, 09 November 2026 12:40 CST

rkonik

Hello,

I've noticed a problem with very slow file scanning in Admin Tools Professional 7.9.4.

My website runs on Joomla 5.4.10, PHP 8.2, and LiteSpeed. The server has plenty of available resources, and the website itself performs well.

However, scanning approximately 14,000 files has taken over 40 minutes. For comparison, I've used much less powerful servers where similar scans took around 10 minutes.

Initially, I suspected a server performance issue, but after running several tests, I noticed something unusual.

With the following settings:

  • Minimum execution time: 0 seconds

  • Maximum execution time: 10 seconds

  • Runtime bias: 75%

each scanning cycle took approximately 18 seconds.

When I increased the maximum execution time to 30 seconds, the intervals between cycles increased to approximately 48 seconds. The complete scan took 42 minutes and 29 seconds.

Interestingly, according to the output of the time command, the total CPU time used during this scan was only about 15 seconds.

I then changed the settings to:

  • Minimum execution time: 10 seconds

  • Maximum execution time: 10 seconds

  • Runtime bias: 75%

After this change, the intervals between scanning cycles decreased to approximately 7–8 seconds, and the complete scan finished in 21 minutes.

This is a significant improvement, but I still believe the scanning process is taking much longer than it should.

While investigating the issue, I noticed the following code in:

administrator/components/com_admintools/src/Model/ScansModel.php

$waitTime = $alreadyRun - $minExec;

I'm not an expert in Akeeba's code, but I'm wondering whether this calculation is correct. It seems that when the minimum execution time is set to 0, the scanner may wait for approximately the same amount of time it has already spent processing the previous step.

Could you please check whether this is the intended behavior or possibly a bug?

I would also appreciate your recommendation regarding the best scanner settings for a powerful server to achieve the fastest possible scanning performance.

Thank you in advance for your help.

Tuesday, 10 November 2026 01:02 CST

nicholas

This is a bug indeed. It should be the other way around: $waitTime = $alreadyRun - $minExec;

Try that, and set Min 0, Max 10, Bias 90%. This should be running for about 9 to 10 seconds per page load with a cool-down time equal to the remainder of the time to reach the full 10 seconds (a maximum of 1 second). With a beefy server like yours I do not expect any issues.

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!

Tuesday, 10 November 2026 12:59 CST

rkonik

Thank you for your help.

I decided to run an additional test to check whether the problem was indeed caused by the subtraction order in the code.

I changed one line in ScansModel.php:

Original:
$waitTime = $alreadyRun - $minExec;

Modified:
$waitTime = $minExec - $alreadyRun;

I kept exactly the same settings for both tests: Min 0, Max 10, Bias 90%.

I ran the scans using:

time php82 cli/joomla.php admintools:scan

Here are the results:

Before the change:

Last Tick : 2026-11-10 13:35:27
Last Tick : 2026-11-10 13:35:45
Last Tick : 2026-11-10 13:36:03
Last Tick : 2026-11-10 13:36:21

real    42m18,065s
user     0m8,096s
sys      0m7,198s

After the change:

Last Tick : 2026-11-10 14:33:47
Last Tick : 2026-11-10 14:33:56
Last Tick : 2026-11-10 14:34:05
Last Tick : 2026-11-10 14:34:14

real    21m9,923s
user     0m8,379s
sys      0m6,498s

As you can see, this change reduced the total scanning time almost exactly by half. The intervals between scanning steps decreased from 18 to 9 seconds.

Both scans completed successfully.

Am I correct in understanding that this is the intended subtraction order?

I'm also wondering why the scan still takes approximately 21 minutes, considering the very low CPU usage.

Tuesday, 10 November 2026 15:27 CST

nicholas

Correct. This is the intended order for that code.

Regarding your comment about CPU usage, I believe you're confused about what time measures, and lacking some much necessary information about how the PHP File Change Scanner, Joomla, PHP, MySQL, the kernel, and the time command work.

The scanner performs two types of I/O operations: it reads files from the filesystem, and it reads (and in most cases also writes) a database record for every file it scans.

Both types of operations involve waiting for other components to complete their work. In particular, database queries are executed by the database server (MySQL or MariaDB), which runs as a separate process. The CPU time consumed by the database server is therefore not included in the CPU time reported for PHP. 

Moreover, MySQL / MariaDB uses a thread-per-connection model. The PHP File Change Scanner runs inside Joomla which opens a single connection to MySQL, and we do one to two queries per scanned file. This has two major implications:

  • Single-core CPU performance matters. Each individual query is generally executed by one MySQL thread, even on a server with many CPU cores.

  • Latency accumulates. If scanning 100,000 PHP files requires two queries per file, even an average of 5 ms per query amounts to roughly 16 minutes and 40 seconds spent on database operations alone.

Furthermore, the operating system schedules CPU time among all running processes, so the PHP and MySQL processes may also spend some time waiting for CPU availability.

The reported 8.379 seconds of user CPU time and 6.498 seconds of system CPU time only tell us how much CPU time was consumed by the PHP process itself. They do not account for the work performed by the database server, or the time spent waiting for filesystem and database operations. Therefore, the measurements you have do not support the hypothesis that the scanner was idle or doing nothing for the remainder of the 21 minutes. We can only conclude that PHP itself consumed relatively little CPU time. 

In my own measured runs, the bulk of the time consumed by a scan is predominantly spent on file I/O and database operations, and that's on machines that are otherwise idle and have plenty of memory to keep the entire filesystem in memory (filesystem cache). This is consistent with what you observe, and does not mean that there's any wasted time, or that the scan could have run any faster. All of it is real work, spread across PHP, MySQL, and the operating system doing filesystem I/O.

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!