Forum Replies Created

Viewing 2 replies - 1 through 2 (of 2 total)
  • Thread Starter qvasi

    (@qvasi)

    It’s been running for about a year or so using the plugin. The settings has been left on default (probably a bad idea) until yesterday.

    The site belongs to a customer, and I just got access to their google analytics so that I could see the worst case throughput to tune the sampling rate. And it seems something *bad* happened 6. december 2017 when I updated plugins.

    Up until then they had a somewhere between 10 thousand and 21 thousand pageviews per day and a bounce rate of about 50%; then the pageviews fell to below 200 pageviews per day and the bounce rate jumped to about 95% percent(!). Clearly they have not been paying much attention to the analytics… (They mentioned that the site had felt slow lately when corresponding with them when we killed the server temporarily yesterday, trying to stop the flow of hour long database queries, but they hadn’t bothered informing us that it was slow before the site actually stopped working, lol)

    Most likely something changed between 7. november (which was the previous time i updated plugins) and 6. december that caused the site to be painfully slow. Not sure if it was the update itself or a transient condition during update or something that messed up the database tables. (It seems unlikely to me that the only thing that happened was that the database just went from “not-too-large” to “too-large” by coincidence the same day I updated the plugins.)

    Maybe it would be a good idea if the settings were slightly more optimized by default for stupid devs like me that forget to even look at the settings? E.g. keeping the data forever and having no caching, seems to be options suitable only for very small sites or if you really know what you’re doing.

    Thread Starter qvasi

    (@qvasi)

    Ok, I modified a copy of the plugin and tested it with 10000 ms (10 seconds) max exec time, and that worked fine on the almost no traffic alternate language site, but it was not enough at all on the high traffic site that originally caused the issues. Most or all of the queries on the settings page failed to complete within 10 sec (but at least that verified that the execution hint actually works).

    I tried using 300 000 ms (5 minutes), but of course nginx that is in front of the wordpress server times out after 60 seconds and gives a 504 Gateway Time-out message when trying to go to /wp-admin/options-general.php?page=wordpress-popular-posts
    I tried reducing the max time to 50 seconds, hoping that it were only one slow query and that it would manage to at least render the rest of the page within the remaining 10 seconds, but obviously there are a lot more queries on that page that adds up to a lot more than 60 seconds.

    I managed to edit the cache and sample rate stuff by copying the url /wp-admin/options-general.php?page=wordpress-popular-posts&tab=tools from the low-traffic server. And the widget does seem to work. But I wasn’t sure if it just worked because it managed to finish within 5 minutes and that result were still cached. So then I cleared the cache.
    And suddenly it was possible to load the frontpage settings. It now appears like it has not been any visitors at all, but there still is hall of fame list with several hundred thousands of views.

    Maybe clearing the cache somehow triggered some kind of cleanup?

Viewing 2 replies - 1 through 2 (of 2 total)