Support » Plugin: Glossary » (apparently a Freemius issue)

  • Resolved eLeXeM


    : /wp-admin/admin-ajax.php?_fs_blog_admin=true slowing down pages to inoperability

    so … “all of a sudden” (which probably transtlates to “caused by some update”), trying to save posts threw us 503 errors (Service unavailable), effectively rendering our WordPress instance unable to save posts. If you get 503s, you go hunting for resource hoggers. Unsurprisingly, our old foe admin-ajax.php showed up at the top of the list again. More surprisingly, tho, with a call clearly reated to Freemius and *drumroll* causing delays by up to almost 6(!) seconds > .

    So I scoured our install for the offending line + it popped up in 7 plugins ( of which, however, only 3 ‘re active when the outage occurs (in order of appearance):

    Here’s the (not so) funny thing, tho:
    For none of those 3, we have opted in to @freemius (but maybe the expecation that this component shouldn’t be making _any_ calls, when opted out of is mistaken. Perhaps that question can also be cleared up with this case, see below).

    Next, hoping to identify the actual culprit, we went the path of elimination.
    We switched off all 3 of the potential offenders, checking the effect after each deactivation:

    Leaving me, at this point of the investigation, with 2 primary questions :

    a) (which is why I’m laying this at your door, @codeat) What is it in Glossary that near doubles the response time of the offending call? (Be reminded that Glossary gave us freemius-related pain before)
    b) (directed at @freemius, cc: @svovaf) why are there still calls to your component bogging down our install when no active plugin is actually set to have opted in to your service?! (Beyond that: if they can’t be avoided – is there any way of figuring out what makes them so abyssmally sluggish? Perhaps even mend that?

    To add, each of the 3 plug-ins addressed herein presented me with an inquiry why I was switching it off – so I’m guessing that’s also owed to freemius :/ contributing to my impression that the service is not actually as dormant as one would assume it to be when not opted in to.)

    Thank you for helping us getting to the bottom of this.
    Cheers – LX / team

    The page I need help with: [log in to see the link]

Viewing 12 replies - 1 through 12 (of 12 total)
  • Hi @elexem,

    Due to WordPress limitations, when a WP Ajax call invoked, there’s no way to programmatically know if the request initiated in the WP Admin or the site front. Therefore, we had to come up with a workaround – adding a querystring argument _fs_blog_admin=true to all AJAX calls initiated in the WP Admin, which then enables the SDK to identify if the call triggered in the WP Admin or not.

    So, the fact that you there are AJAX requests with ?_fs_blog_admin=true doesn’t mean that the SDK sends any data. To double check that you can install Query Monitor and check if there are any API calls to *

    Regarding the slow down, try to deactivate Glossary and activate Featured Images For RSS, and see if there’s still an impact on performance. If it does, perhaps the slow down is somehow related to the SDK. If it doesn’t, most likely an issue with Glossary.

    Hello @svovaf + thank you for getting back to me re this.

    • ackowledged re the identifcation of calls from the backend.
    • interestingly, looking at HTTP-API-calls, Query Monitor states “No HTTP API calls.” Which confuses me, tho; because:
    • right now, all 3 potential offenders are off, so what would possibly cause lines calling admin-ajax with your admin identifier?

    The remaining 3 lines showing the bogging string gave some more clues, hovering over the “initiator” bit. Aside from generic / core pointers

    • the first 2 point to something named “blcDoWork” – I’ll have to identify to which component this belongs
    • the second one to permalink_manager_duplicate_check of Permalink Manager; I’ll switch this off for just another eliminiation step; but this is actually indispensible (we’re even running the Pro version).
      Result: This test left only one line behind, the one belonging to “blcDoWork”, totalling 2.26s delay. Hmm. Now I’m even more confused. Because Permalink Manager didn’t even surface in the initial search for the string (see first post). Perhaps @mbis can add some more insight re this detail?
    • In the meantime, I’ll go try find out what this “blcDoWork” is + where it originates.

      Cheers –

    Maybe you have another plugin that use freemius?
    Anyway let me know if there are issues with Glossary and we will check it!

    🙂 ciao, Daniele (@mte90);
    well, do you consider it an issue that your plugin doubles the response time of those calls in question? (see above

    switching off Glossary, however, cut the response-time by half (while over 3 seconds is still utterly inacceptable) :


    (as to the other bit : “blc” is > Broken Link Checker)

    Either way, tho’ – all of those calls related to freemius are taking ridiculous amounts of time + I’m still unclear why they have to occur at all, where opted out.

    I am trying to understand the problem but is very difficult to replicate the issues for me right now.

    I’m sincerely sorry I can’t be of better help, Daniele :/ I tried to describe it as best I could.

    Perhaps the difference becomes spottable if you install Glossary on a fresh WordPress and choose to opt out of Freemius on that, and then have a look at the page performance waterfall/s when saving a post or a page. That’s where it hit me.

    :/ #hth – best – lx

    I did few tests with skipping of freemius on installing in a clean install.
    I didn’t see any request with query monitor on the page

    that is weird.
    Did you run page loads monitoring the waterfall?

    we are releasing now a new version with the latest version of the freemius sdk, so maybe should fix the issue.

    Released a new version with the new freemius sdk release

    Thank you very much, Daniele;
    I’ll give it a test at the earliest chance I get;
    might be on or after the weekend, tho;
    bit tied up the next couple days.

    Thanks either way already 🙂

    Cheers + ttys – LX

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘(apparently a Freemius issue)’ is closed to new replies.