Poor performance

  • Resolved sologne

    (@sologne)


    7 years ago

    While the features of the plugin are interesting, there is a serious performance issue.

    I noticed it once with P3, but I recently nailed it with another tool.

    These database calls seem to play a big role :

    UPDATE wp[db]_options
    SET option_value = ‘1510900168’
    WHERE option_name = ‘_transient_timeout__redux_activation_redir

    UPDATE wp[db]_options
    SET option_value = ‘1’
    WHERE option_name = ‘_transient__redux_activation_redirect’

    It represent A LOT of lost time – more than half of the database queries time on my homepage ; around 0,4s in the pageload from which I retrieved the queries. That’s huge.

    Are these options update really necessary ? Is it really wise to play here with SQL queries ?

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

    (@brianmcculloh)

    Those calls are part of the Redux options framework, which is a third-party options framework used to create the plugin options admin screen. If you need support with that component, please head over to Redux support: https://github.com/reduxframework/redux-framework/issues

    Thread Starter sologne

    (@sologne)

    Well, it’s your plugin. Issues with what you use to build your plugin should be your concern too.

    I reported to you the issue kindly, with relevant information to help you know not only that there is an issue but where to search for a fix.

    But after that, I’m not a programmer of this plugin. I won’t comment on technical decisions I’m not in a position to evaluate. Do you need to use this ? Is it a defect in redux or in the way it is used ? I don’t know the answers and I shouldn’t have to either. What’s the point of bug-reporting if the answer is “fix it yourself” ?

    To be clear, I wouldn’t care much if this manifested itself only on an options admin page seldom accessed… But these calls seems to be fired on each page load, be it on main page or articles.

    Other plugins use a lot of options too, and they don’t need to do such costly calls to use these options.

    Even supposing it’s redux which is defective, then deciding to keep using it is not a neutral choice.

    That’s your plugin, you know it much better than me. Understanding why those calls are done, if you can avoid them in the way you use redux, if you need to request a change to redux (and if yes, which), or ditch it altogether… All those are things you could do and that I can’t.

    However, whatever the way chosen, you really need to fix it. WtR is a “nice-to-have” feature, but not a “must-have”. Such an overhead and lost load-time is unacceptable for such a feature.

    Plugin Author brianmcculloh

    (@brianmcculloh)

    You don’t happen to have wp_debug turned on when you notice this, do you? Because that puts Redux into dev mode which might be the cause of this.

    Thread Starter sologne

    (@sologne)

    Hello,

    I double-checked, and I can confirm you that wp_debug is off in the wp-config when I notice the issue (explicitly off with the default “define(‘WP_DEBUG’, false);”)

    Plugin Author brianmcculloh

    (@brianmcculloh)

    Thank you for confirming that. I need to look into why this would be loading on every page. Thanks for pointing it out.

    Plugin Author brianmcculloh

    (@brianmcculloh)

    We have released version 1.4 of the plugin which fixes this issue. Please update and let me know if you continue to experience any further issues. Thanks again for contributing to WTR’s success!

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Poor performance’ is closed to new replies.