Server Load / CPU Usage / Page load time

Thanks for your feedback. I have not experienced that myself. I’ve run P3 Plugin Profiler but can’t see that Simple History uses any CPU at all there. Could you post a log/screenshot of your findings here or email me at [email protected]? Thanks!

Sure you bet P?r. Thanks for your reply.
I’ve been doing a ton of upgrades and experiment so just bare with me as I need to make sure nothing else is running to hot before I do some tests with this plugin. I will email you.

Hello,

sorry to say : same here.

Runtime by Plugin : 58% for simple history
Memory Usage: 103 mb without simple history : 75 mb
MYSQL Queries: 123 without simple history : 118

@onirgoc: on what page is that? is it on every page or just on dashboard or the simple history page?

Hello,

landing page.

In my testing Simple History does not perform any sql queries on the frontendt. Could you post the queries it does? Perhaps there is a them/plugin conflict somewhere.

Something I have noticed about the P3 Plugin Profiler in the past (not sure if it still does this now/anymore) is that if you deactivate other plugins that you have activated and then run tests again the P3 results are different. Also try deactivating the Simple History plugin and run P3 tests again and see if a different plugin that you have installed is now showing high usage. My hunch is that the way P3 checks “ticks” is that when it gets to the last plugin activated then there is some kind of additional usage tacked onto that plugin that is not exactly accurate.

I have not tested this theory out, but hypothetically if you install an additional plugin that has a plugin name starting with “t,u,v…” then it would be seen as the last plugin installed/activated by P3 and P3 appears to check in alphanumeric ascending order so a plugin name starting with “t,u,v…” (any alphanumeric character greater than “s”) would be checked last and in theory would be where the skewed P3 results would occur.

Thanks AITpro for your input !

Well in fact my thought now, after few tries to reduce all ressources needed to make my wordpress site work, is that all those efforts will not be enough to reduce enough necessary ressources.

So, as Simple history is a very usefull plugin and I can’t imagine not to use it and as my host (site5) doesn’t seems to be very flexible about ressource (grrrr….) the solution is to change host ! siteground ? any advice ? I can’t pay for dedicate server for now.

@p?r Thernstr?m
It’s really difficult to put more time on debuging simple history and I even don’t know how to find out what are the queries…so if you can be more precise on how to find these infos…

@onirgoc – It is frowned upon and maybe not allowed to discuss Hosts like that in the WP Forums so I cannot make any suggestions about Hosts in the WP forum. ??

@onirgoc: try Query Monitor, it can show you all queries for any page.

Hello

Sorry to say but I disable simple history until I find a good solution because here it is some comments about CPU usage from my host site5:

The resource usage is in relation to your accounts specifically, rather than the server. The usage for the 17th was just a bit over the limits, however nothing like prior. This was notably due to the heavy activity from admin-ajax.php, with over a thousand executions of the script such as:
/wp-admin/admin-ajax.php?action=SimpleHistoryNewRowsNotifier&apiArgs%5Bsince_id%5D=2023&apiArgs%5Bdates%5D%5B%5D=lastdays%3A14

This may be due to a plugin running that is causing the ajax script to be called. This is the heartbeat API of WordPress. This script is known for being resource hungry, because if you leave the admin pages open in a separate tab for instance, it will constantly be reloading itself. You’ll see the resource points increase, or if the host doesn’t have a measurement in place then the cpu and memory will spike and this script alone can cause problems for a server performance and result in that account being disabled, as can be seen with various articles on the web.

A good thing to do is disable or adjust this heartbeat api which there is a great article on at: https://www.inspire2rise.com/how-to-disable-wordpress-heartbeat-api.html

Of course if this is a plugin specifically then you can check whatever plugin uses that SimpleHistory function.

I already add this to my function child theme:

add_action( ‘init’, ‘stop_heartbeat’, 1 );
function stop_heartbeat() {
wp_deregister_script(‘heartbeat’);
}

So I think with that code simple history will not work anymore ? am I wrong ?

I have not used P3 for a long time and it looks like a lot of things have changed in P3. I no longer see individual plugins listed and the newer graph timeline shows points where spikes in Queries can be hovered over to see what is responsible for those spikes. Overall it looks like P3 is very accurate now. I installed and tested both P3 and Query Monitor and Simple History and I definitely do not see any signs of excessive resource usage. The calls to admin-ajax are reasonable, not excessive and well within a normal range. Overall site performance (frontend and backend) is not impacted significantly by Simple History and is well within the “normal” range of Query and resource usages.

So based on these tests in my specific environment then a logical explanation for what may be occurring in your specific environment is you have a combination issue/problem going on. ie there are several factors to consider, such as a specific host server configuration issue (php.ini, .conf or other) could be involved in a combination problem or something else you have installed could be conflicting with Simple History. Simple History installed on my testing server with 4 other plugins activated on PHP5.6 performs very well and well within good overall website/server performance parameters.

hmm interesting. P3 works differently on a Local Development server vs a Live Hosted server. My previous testing was done on a Local Dev server. On a Live Hosted server I tested these scenarios and these are the results.

Simple History consistently uses a range of .13 to .18 plugin load time seconds and if you are looking at the usage percentage (Plugin Impact of page load time) then that is going to throw you off. The total Plugin Impact percentage is relative to everything that is loading/being used and should not be looked at like overall website/server resource usage on the website/server. Example: of the total percentage of things loading X is using X%.

My theory about alphanumeric ascending plugin name ordering skewing results for the last alphanumerically oriented plugin is incorrect/wrong. I installed WooCommerce to test that theory and then other plugins to test and disprove that theory. ie higher and lower alphanumerically named plugins. What does occur is that the usage percentage decreases for Simple History when you install more plugins because the usage percentage is relative to the total number of things installed that are using resources, but Simple History is consistently within a range of .13 to .18 plugin load time seconds. Overall executed Queries is well within the acceptable/good range.

@onirgoc: calls to /wp-admin/admin-ajax.php?action=SimpleHistoryNewRowsNotifier&[...] is only done when you have the log from simple history opened in a browser tab. If you have the plugin page with the log opened in a tab, then yes it will every 10 seconds make a call to the server to check for new events.

@aitpro: I did try P3 Plugin Profiler on two of my sites, but none of them showed Simple History at all among the plugins in “Runtime by Plugin”. So very unsure how to debug this. Maybe a conflict with another plugin that causes this. But since I don’t have this problem myself there is not much I can do at the moment.