Manni02

I reported the issue with all PDF Embedder since V5.1.1 months ago and haven’t received any reply yet.

While later versions improved some of the issues, V5.1.4 released recently still displays the watermark wrongly, as V5.1.3 did before it, so I had to revert back to V5.0.2.

I have cancelled my license renewal due to the absence of support. If this is not to be expected, how are we supposed to get support, given that you don’t reply to support tickets?

Hi Anthon,

Thanks for the update, that’s great news!

As long as the fix is in the pipeline, there is no hurry.

Cheers!

Hi Anthon,

I’ve just installed the latest version of the plugin (9.0.14 released yesterday), and site health in WP 6.0.3 still reports a critical issue when plugins are managed by your plugin.

Do you intend to correct this, or are you happy for a critical issue to be reported whenever we use the plugin to manage plugin updates through custom updates, which is one of its main features?

Alternatively, how do you suggest we use the plugin to selectively manage other plugins so that we don’t get a critical issue reported by site health?

Now that site health is included in WP core, surely this isn’t to be considered an incompatibility between plugins (I don’t use the site health plugin anymore).

As far as I’m concerned, Easy Plugins Manager isn’t compatible with WP anymore due to this critical issue reported, so I’ll have to find an alternative if you don’t plan to resolve this incompatibility, given that the Site Health team has made it clear that it wasn’t something they could address their end.

I have no other critical issues reported by Site Health, and I like to keep it that way ??

Thank you!

Hi there,

In addition to the above, Marius from the Health Check plugin has posted a reply in the thread I opened about this issue here: https://www.ads-software.com/support/topic/issue-with-easy-update-manager/#post-16014951

They say that “The plugin could filter the Site Health checks to account for this, and make sure that the auto-update checks are reported depending on the settings of that plugin instead :)”.

I believe this is what could be done when “custom updates” is selected, given that auto-updates are not prevented in all cases but only for some plugins or themes?

They consider that the issue is on your side, so they have closed the thread.

I hope you’ll find a way to filter the Site Health check in this situation, as it would resolve this issue.

Many thanks for considering doing so.

Hi Anthon,

Thank you for this reply.

Yes I’m using the latest EUM 9.0.13.

I agree that if I select “Auto-updates” for both plugins and themes, the Site Health message goes away, but I believe that this critical error message should only appear if the user selects “Manually update”.

That’s not what I do. I select “Choose per plugin” and “Choose per theme” because I want to be able to block some updates. This is the main reason why I’m using your plugin. For example, I use a specific version (“no conflict”) version of the S3 Mediavault plugin, which has to be installed manually and isn’t updated as often as the standard version. Your plugin prevents WP from reporting when an update of the standard version is available. I can’t do this if I set both plugins and themes to auto-updates, plus if I do this I could just as well uninstall your plugin :).

Again, there was no issues with Site Health using the same settings until V1.50 of Site Health. If I downgrade Site Health to V1.45, the critical error goes away.

There is no conflict between EUM and other themes and plugins either. If I disable EUM, the critical error goes away too.

It seems to me that something has changed in V1.50 (or in the WP implementation) in the way Site Health incorrectly reports a critical error when auto-updates are managed by EUM.

So it would be great if you or the Site Health folks could correct this, because my settings have never triggered a critical error in site health in the past, and I don’t believe they should.

Thanks!

• This reply was modified 2 years, 6 months ago by Manni02.

Troubleshooting helps to troubleshoot a plugin without having to create a staging site by selecting the default theme and only enabling the selected plugin(s), but only for the admin, not for the site users.

Tools allow you to check for various php version compatibility for the plugins, check file integrity and a few other things. Install the plugin to find out! It adds two or three tabs that are not present in the version integrated into wordpress.

The version that is now part of workpress only has two section, Status and Info. If you want to use the Troubleshooting or Tools section for example, you need to install the plugin.

Hi Saumya,

Thanks, I’m happy to keep the interval at 4000ms, it doesn’t add much load and I get my 100% idle time back, so the plugin is mostly transparent from a performance point of view with that setting.

Regarding the number of cores, where does that leave us?

I don’t understand what the command you’ve asked me to run via ssh does or means.

Currently your plugin returns 1 core, when the number of cores (as confirmed by Cloudways when they ran the hmod command and sent me a screenshot) is 2.

So what do you want me to tell them? I have no idea what their suggestion meant, or what the result to the command you asked me to run means.

Is there a way to fix this and get the plugin to report the correct number of cores?

Or even a way for me to get the info through SSH?

Or do we just drop it?

• This reply was modified 2 years, 7 months ago by Manni02.

Please read my answer above to your question (it’s 1 if you meant running your command though ssh).

I have done more thorough testing regarding the WP Server Stats interval settings.

I’ve done all the testing in a staging site with the default 2022 theme and all plugins disabled.

The results below are 100% consistent and repeatable as far as the general behaviour is concerned. The actual numbers are averages, they don’t really matter, what matters is the obvious CPU load that the plugin adds to the load reported with the default setting of 200ms, and how much you need to add to make it mostly neutral and actually report the CPU load itself, and not the load added by the plugin itself.

I double checked with the server monitoring, and although there is a strong lag with the server graphs to take into account, there is no doubt that the plugin is reporting the actual CPU Load in real time, so I won’t make a distinction between server monitor and plugin CPU load. Once I established that they always matched, I used the CPU Load reported by the plugin because it’s in real time, except for measuring the baseline.

For the idle time monitoring, I used the server, taking into account the 5-8 min latency between what’s measured and what the graphs report.

I always waited for the reading to stabilise when accessing the dashboard, as it can take 5-10 secs before all the blocks display their data in the production site. It’s much faster on the staging site with no plugin, but it still takes a little while. I didn’t take into account the very occasional larger readings that are probably caused by some internal action.

Here you go:

Baseline with or without Admin Panel access, server monitoring:
WP Server Stats disabled, default 2022 theme, no plugin: CPU Load 0-1% Idle 100%

With Admin Panel Access and WP Server Stats plugin enabled:
WP Server Stat enabled, 200ms (default): CPU Load 10-25% (mostly 16-17%), idle 99-90%
WP Server Stat enabled, 1000ms: CPU Load 1-15% (mostly 10-15%), idle 99-90%
WP Server Stat enabled, 2000ms: CPU Load 1-12%% (mostly 5-10%), idle 99-90%
WP Server Stat enabled, 3000ms: CPU Load 1-6% (mostly 1% or 5%, swaps every reading), idle 100%
WP Server Stat enabled, 3500ms: CPU Load 1-6% (mostly 1%, occasional 5% every 15 secs or so), idle 100%
WP Server Stat enabled, 4000ms: CPU Load 1-6% (mostly 1%, very occasional 5% every 30 secs or so), idle 100%
WP Server Stat enabled, 5000ms: CPU Load 1-6% (mostly 1%, very occasional 5% every 40 secs or so), idle 100%
WP Server Stat enabled, 7500ms: CPU Load 1-6% (mostly 1%, very occasional 5% every 50 secs or so), idle 100%
WP Server Stat enabled, 10000ms: CPU Load 1-3% (mostly 1%, very occasional 3-5% every 60-90 secs or so), idle 100%

So anything from 3000ms gives me my 100% idle time back as per the server monitoring, and at most 6% above the baseline (plugin disabled), though the value reported is often inflated up to 3500ms. Note that the added CPU Load is 16-17% with the default 200ms value (which confirms the 25% I reported when all the other plugins are enabled on the production site).

In the end I settled for 4000ms, which only gives me an inflated reading every 8 readings or so, which I find acceptable as you have to wait 3-5 secs after displaying the dashboard anyway (5-10 secs on the production site) for the readings to stabilise, so I know that once it settles, the CPU Load reported is likely correct for 20-30 secs, and if infladed it won’t be more than 5-6%, instead of 16-17% with the default setting of 200ms.

I would be curious to know if it’s something you can reproduce on your server, and if there is any way to optimise that so that we can get more frequent updates without hammering the server that way.

• This reply was modified 2 years, 7 months ago by Manni02.
• This reply was modified 2 years, 7 months ago by Manni02.
• This reply was modified 2 years, 7 months ago by Manni02.
• This reply was modified 2 years, 7 months ago by Manni02.
• This reply was modified 2 years, 7 months ago by Manni02.

If you mean with SSH, the answer I get is 1

Hi Sauma,

Thanks again for your reply.

So I checked with CLoudways and here is their answer:

1) I got it wrong, I don’t have 3-cores currently, only two. I did test 3-cores/8GB initially but there was no performance gain for our needs, so I went bakc to 2-cores/4GB. Doesn’t change the fact that the reporting is wrong in the plugin, but it’s not because of an odd number of cores on the server as I incorrectly guessed ??

2) They checked with htop and produced a screenshot showing that the server had indeed two cores. I can send you the screenshot if you wish.

3) I gave them the information you kindly provided above, as well as the exact command you use, they did more checks and here is their answer:

You may ask your developer to check like this:
?
? cat /proc/cpuinfo | grep processor
?processor : 0
?processor : 1
?
?Basically, He will see 2 processorts starts with 0 and 1

Does this make sense to you?

I’ll need more time to investigate the CPU load, but I’ll get back to you later on this.

• This reply was modified 2 years, 7 months ago by Manni02.
• This reply was modified 2 years, 7 months ago by Manni02.
• This reply was modified 2 years, 7 months ago by Manni02.

Hi Sauma,

Thanks for your reply.

I did test with and without the plugin enabled to identify this issue. I have no excessive CPU load if accessing the admin panel when the plugin is disabled.

I look at the server monitor data on Cloudways, it clearly shows that when the user accesses the admin panel, enabling the plugin uses around 25% CPU power and decreases idle CPU time from 100% to 60% with the 200ms default.

Of course I take into account the fact that there is a delay of about 5-8 minutes in the user monitoring data shown to the user on Cloudways, as the graphs are only updated every five minutes even if you refresh them more often (at least that’s the case for the idle time one). So I leave enough time for each state (plugin enabled or disabled) to register and show.

Raising the interval seemed to help initially, and I realised it was only temporary.

I would need to do more testing looking at the logs to see if I can pinpoint what the plugin does that causes this if you’d like me to. By the way, the higher CPU load happens even if you’re not looking at the dashboard, i.e. if there is no need to refresh the server stats information. Would there be any way to get the plugin to only use CPU time when a refresh is actually needed, i.e. when the admin is looking at the dashboard, or are you showing the information elsewhere? You might be showing it at the bottom of each admin page, in which case it would be great if we could have an option to disable this and only show the server stats when looking at the dashboard.

Of course if I’m the only one experiencing this and if you can’t reproduce looking at your server monitoring, then no need to to anything.

Do you have any idea reagarding the misreporting of the 3-core CPU on the server as a 1-core?

Thanks!

• This reply was modified 2 years, 7 months ago by Manni02.
• This reply was modified 2 years, 7 months ago by Manni02.
• This reply was modified 2 years, 7 months ago by Manni02.

Nope, that was only temporary. Even with 5,000ms, the load is still much higher than when the plugin is disabled. I guess I’ll keep it disabled most of the time, and will enable it with the default 200ms when I actually need it.

Sorry, it looks like I had missed the settings page ??

I found it and raised the realtime script refresh interval to 1500ms and that resolved the high CPU usage issues (it’s back to 1-2% when nothing happens). 1000ms cut the load by half but the iddle time was still at 80%. 1500ms brought the iddle time back to 100%, as when the plugin is disabled.

So I guess it’s just the cosmetic issue of the odd number of cores that remains ??

• This reply was modified 2 years, 7 months ago by Manni02.
• This reply was modified 2 years, 7 months ago by Manni02.

You’re very welcome, I hope the devs didn’t feel left out because I fully include them in my praises! ??
Keep up the great work