Comparatively slow scan on one server

That’s interesting, thank you for sharing!

I assume your two set ups contain different user content (uploads and such)? A good way to quickly get a head-to-head comparison would be to do core-only scans on each system; that way it will scan the same files on each system.

If the core-only scan performance is more or less the same for both, then the performance issue comes down to user content. Setting a reasonable upper file size limit should address this (try setting a limit of 1MB; most scripts will be much less than this). This way the scanner will not struggle generating a checksum on large images or video or whatever.

If the core-only scans are still completing at very different rates, then there must be something unfortunate in the Linux set up. You might need to adjust the memory and cache settings in PHP, MySQL, and/or Apache (or NginX or whatever server software you’re using). Benchmarking and monitoring software might help you locate areas of strength and weakness in the set up.

That is strange. I too have always found Linux to be much faster than Windows, except on really bad shared hosts (of which there are too many, haha).

To help narrow it down further:
When a scan is first started, there is a pre-scan of sorts, where the plugin crawls the directories and compiles a list of files to later scan. This pre-scan is completed once you first see the progress bar. Is this portion slow on the Linux server too, or does it complete in a comparable time (shouldn’t be more than a second or two) to the Windows version?

The scan itself is pretty simple:

1. An AJAX query is submitted to WP.
2. Look-See queries the database for up to 250 file paths to scan. This uses the WP database wrappers, and so shouldn’t itself be a point of slowness if WP queries are normally speedy.
3. For each file, it first checks to see if it exists (if not, the db is updated to note this);
4. Assuming the file exists, it then checks the file size to see if it is larger than the allowed limit (if larger, the db is updated to note this).
5. If the file exists and is within the allowed size range, it computes an MD5 checksum of the file and saves this value to the db.
6. Once every file is checked, it returns a couple totals, and if there are more files to check, the process is repeated.

From the above, there are three good candidates for slowness:

A) Checking the file size has a performance penalty, but usually this is greatly outweighed by the savings of not MD5ing massive files.

B) MD5 computations take a bit of time to perform. Less than stronger checksums, but more than something like CRC32. Overall it seemed the sanest choice of checksum algorithms.

C) 250 separate update queries, though small in size (we aren’t transmitting Moby Dick…), might still be more than MySQL wants to be bombarded with. A future version of the program will allow this value to be easily toggled, but if you wanted to quickly change it yourself, it is set at the top of the plugin’s index.php file: define('LOOKSEE_SCAN_INTERVAL', 250); A smaller size will result in more AJAX queries to the server, but lighter loads per query.

Thanks a bunch of helping me debug/improve the plugin!