Thank you very much for reporting this one. I was 100% confident the plugin was efficient, well, that’s not the case š
What you observe is not supposed to happen. The plugin should look for updates once a day, not once per page load. The first easy and safe fix would be to move this action to the admin part. With this, whatever happens, only the admins will be impacted, not the regular visitors. Then, I need to find out why the action is called that many times.
I can’t address this right now but obviously this is my top priority issue.
FYI: I’m not 100% sure that the performance problem is caused by that API call… It just seems like that, but it may be something different… I will do some debug tests today and I will let you know if I can find the cause.
hmmm… I was going deep to your code, and it seems like there is nothing wrong…
Your plugin seems to just load, take the value of “fbrfg_html_code” using get_option() and just insert it via wp_head hook, right?
Weird is, anytime I enable the plugin on my site, CPU usage goes up to 2x normal state or more, but as I’m looking to the code, there is no reason for that…
I just run the test with your plugin and simulating 100 concurrent unique visitors to HP (without cache) and successfully take the website down š The core problem for the server was MySQL connections… Don’t want to believe that this can be caused by just get_option() š
I need to go deep in our rewrite rules and other WP hooks… there may be just some kind of collision with other plugin or even template code.
Yep, that’s really weird š
As you noticed, the “core” of the plugin is very light: inject some code if get_option returns something. With all WP code and regular plugins on board, I guess get_option runs a dozen of times on each page load.
However, I did two things:
– Update checking is done in the admin section. So if anything wrong happens here (eg. update checking is run too often for some reasons), only the admins are impacted.
– Locales are not loaded anymore in the public section. That was completely useless anyway. As for get_option, I don’t think this is the kind of “heavy processing” that might put a site on his knees. However, if you are willing to make some experiments, you can comment the line add_action( 'init', array( $this, 'load_plugin_textdomain' ) ); in class-favicon-by-realfavicongenerator.php and see if it’s better.
These changes will be part of version 1.2.12, to be released in a few days.
The fix was deployed a minute ago (v1.2.12). I hope that will solve your issue!
Sorry to ask, but did you have the opportunity to retry?
You already spent a lot of time on this issue, so it’s okay if you don’t want to work on it anymore!
sorry… I just didn’t have the spare time… I’m now busy compiling and submitting several apps to iOS and Android stores. I will check the fix later this week š
I’m sooo sorry for my speed and slow response š
The good news is, that after the update, I can’t overload the server… whatever I try to do, website is still fully responsive. Server load impact is the same with and without the plugin.
so…. the problem is fully resolved š thank you and sorry again for my slow reply š
Thank you very much for having taken the time to check this one more time!
Good! So the fix seems to be effective.
