Multiple Sites & Scheduling

Wow that is pretty bizarre, I am looking through the codebase now with this in mind trying to understand what could cause the scan to trigger across all of your sites at once, and I am feeling a bit stumped.

I will detail here what happens when you press ‘Start Reporting’ at the top of one of the plugin pages:

1. The plugin stores an option in the DB called “gpi_check_now” with a value of true
2. The site then sends a non-blocking remote post to your site to a special URL, which will check for the ‘gpi_check_now’ option, and start the scan if it exists, and then remove the option

This functionality is based on how the WP cron functionality works ‘under the hood’.

All of the above behavior is specific to the URL returned with the WP site_url() function, and also specific to each DB having the ‘gpi_check_now’ value.

Now in addition to that functionality, there is also a more traditional cron, which can be configured in the options page, and is configured on by default. However the actual cron does not get scheduled until the settings page is saved. Once again this should be encapsulated to just one site at a time.

This is something that will be very difficult for me to recreate and debug in my environment, but hopefully some of the information above about how this plugin triggers scans helps to narrow things down on your end?

Matt Keys

Hey @drokkon,

I just wanted to let you know I actually ran into this problem myself today, and was able to find the cause of it.

I have a solution worked out in a new version of the plugin which will be going into beta testing soon. I will let you know when that happens if you’d like to be a tester.

Matt Keys

@drokkon

The new beta is now available for testing, it includes what I believe will fix the problem you were seeing. If you are able to test out the beta and let me know if it resolves the issue for you, I’d appreciate it.

You will find instructions to download here:

https://www.ads-software.com/support/topic/v4-0-0-beta-1-needs-testers/

FYI, the new version of the plugin with this fix is out.

Wow – thank you SO MUCH for staying on top of this! What was the issue, if you don’t mind me asking?

It was a fun one.

It is important for this plugin to only run a single scan at a time (per WP install). I accomplish this using a feature of MySQL called a ‘mutex’.

Before a scan starts, I check if a mutex lock has already been established, and if it has, the scan doesn’t start (because that means a scan is already running).

If there is no mutex lock established, at the start of a new scan we establish one, passing it a unique key that can be used later to check if there is a lock, and also to release the lock.

During the pagespeed scan, I also check for this lock to know if I need to show the progress bar at the top of the GPI pages.

Once the scan is finished our lock is released.

This all works well, but I learned something I did not know about these mutex locks, their ‘scope’ extends beyond the DB that WP is installed to. It covers any DB on the same MySQL server.

So one instance of WP running GPI could get a mutex lock, and other WP sites on the same MySQL server would not be able to establish their own lock because they think a scan is already running.

The solution to this was to create and store a unique mutex key for each installation of GPI.