Support » Plugin: Google Pagespeed Insights » Multiple Sites & Scheduling

  • Resolved jOt Creative

    (@drokkon)


    I have two dozen sites on a server that I’d like to measure. They each have a separate cPanel account and a separate database.

    I used a single API key for each of them, and then when I ran a check on one of them, was surprised to see the other sites showing that they were being scanned. Since a few showed that they were being scanned before I even had a chance to enter the API key, I’m guessing a shared CRON is to blame?

    In any case, how should I set this up? Separate APIs? Is there a way to make sure that they don’t all run at the same time?

    Thanks!

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Matt Keys

    (@mattkeys)

    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

    Plugin Author Matt Keys

    (@mattkeys)

    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

    Plugin Author Matt Keys

    (@mattkeys)

    @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://wordpress.org/support/topic/v4-0-0-beta-1-needs-testers/

    Plugin Author Matt Keys

    (@mattkeys)

    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?

    Plugin Author Matt Keys

    (@mattkeys)

    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.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Multiple Sites & Scheduling’ is closed to new replies.