Poor website performance

Hi @alanjacobs

Thanks for take your time reporting this!

It’s strange that your analytics are reporting that AutomatorWP is causing those slowdowns, mainly because AutomatorWP was designed with the most performance mechanism

For integrations:
AutomatorWP does a PHP check to meet if the integrated plugin is installed in the site
For example, when you install GamiPress, it’s main class, named GamiPress too, gets loaded in your site (as well as for WooCommerce, or any other plugin)
AutomatorWP just checks if that class exists, making the process extremely fast because there is no any database query involved

For automations:
No matters the number of automations you have in your site, AutomatorWP does not makes use of them until a user have completed all their triggers
For example, imagine an automation that has the triggers “User completes a purchase” and “User earns 100 points”, this automation does not get loaded at any moment, just at the moment a user makes a purchase is when one of the triggers will get loaded
If the user just have completed one of the triggers, AutomatorWP will add just 1 database entry to meet it
At the moment the user completes the other trigger, is the unique moment that the automation will get loaded to meet it’s actions and execute them
All those processes are also made with an internal cache that AutomatorWP builds at the moment you are configuring the automation, to make any automation execution extremely fast

Also, AutomatorWP is made based on GamiPress, our first plugin which is core have been developed and improved during 6 years, so AutomatorWP is benefited from all the good practices and performance mechanisms (cache, query performance, the minimum code checks at possible, etc) to make it a lightweight plugin

Even we tested it in low resources servers to ensure that will have the lowest impact to your site

So some of the recommendations to speed up your sever are:
1 – Use PHP 7 or higher: after PHP 7, the PHP engine has been improved a lot making it extremely faster
2 – Switch your tables engine to InnoDB: much hostings use MyIsam engine on its databases by default which is much more slower than InnoDB, this simple change can speed up your site twice since all database queries from WordPress and the plugins you are using will be more faster
3 – Repeat your tests switching your theme: Commonly themes are plenty of features, but also much of them are overloading the site since they work in the most critical place, the frontend, commonly people check first the plugins for slowdowns, but from our experience we see a lot of times that the one who causes much of the slowdowns is the theme, so do not forgive it in your test since is one of the most critical pieces

Hope that will all those recommendations you can find the slowdowns causes from your site!

Best regards

Thanks. As I said I may be misinterpreting the results …

I already use PHP 8.0
I already use INNoDB
Theme is GeneratePress, although I don’t really use any of it as Elementor pretty much replaces it all.

This was a 2 hour snapshot. No automations ran at this time. So this was just people viewing pages in the site.

I am aware that I have some performance issues – hence running the monitoring. What surprised me was the results.

I have now kicked off a 4 hour monitor period and I’ll see what that raises.

Cheers
Alan

Yes please, keep me up to date with any tests you did ??

Hi, I ran the monitoring again for 4 hours last evening. Results pretty similar.

Slowest plugin:

Plugin ** Total Duration % ** Total Duration time ** Max duration ** Average Duration ** Rate per minute
automatorwp ** 33.35% ** 64,561.27 ms ** 112.15 ms ** 0.46 ms ** 2,332.35

Slowest WordPress Hooks:
action:automatorwp_pre_init ** 24.67% ** 59,016.44 ms ** 112.15 ms ** 1.91 ms ** 515.083

I’m wondering if the code ( hook ) is firing on lots of pages hence the high rate.

Cheers
Alan

Hi @alanjacobs

Thank you so much for your report!

Our team investigated this issue in depth and released a new update (2.1.7) with a great improvement reducing the database calls for check if AutomatorWP tables exists from 8 calls to just 1 call!

You should notice a great performance improvement with that one.

About the monitoring you are doing? How it determines this data? Because if, for example, is checking the times a hook is called, is normal that our pre-init, where all integrations does its checks, give you a high rate since it’s called multiple times.

But the important thing is that, even called multiples times, every call involves just a small PHP check that takes no time as explained in my first reply.

Also, have you checked your site using Query Monitor or a plugin like?

Query Monitor gives you a ton of useful information like duplicated database queries, slow functions and hooks, so with a plugin like that you can find which plugins are causing slowdowns at your site.

Please, let me know if with 2.1.7 update you experience a great improvement.

Wow thank you!
I have installed the new version on live now. It gave no issues on staging.
I’ll run the same 4 hour monitor at the same time this evening to try and compare.

I am using the APM application performance monitoring tool provided as part of my Kinsta hosting. https://kinsta.com/apm-tool/

I can drill down into individual actions and see a lot of detail ( More every time I use it! )
On yesterdays run I can now see that it seems that the pre_init hook is running on lots of pages. E.g. I have a forum and it runs when a user browses a topic in the forum. So I think that although the individual calls are short the cumulative effect is noticeable.

I’ll report back after tonights monitoring run. After that I’ll also look at PerfMatters to see if I can reduce all the unnecessary code loaded on every page ( not yours so much, but Woocommerce and others really aren’t needed outside the shop area. )

Many thanks for your support, much appreciated!
Cheers
Alan

Hi,
Ran the 4 hours of monitoring again last night.

Automator still appears near the top but much improved, so huge thanks!

The only concern I now see flagged is a slow hook called from Wordfence to AutomatorWP_Integration_wpDiscuz
I have no idea why Wordfence is the initiator ( request url = /?wordfencesyncAttackData=xxxxxxxxx ) and it only took 130ms so not really bad.

I’ll play about with Perfmatters to see if I can stop some of the code running on all pages – not an AutomatorWP issue, just a general WordPress bugbear.

Again huge thanks for your help
Cheers
Alan

Hi @alanjacobs

Glad to see you found something with this last monitor test!

Is possible that Wordfence, trying to detect vulnerabilities, is calling every plugin file with this URL you found, but for sure the Wordfence team can guide you to meet why this is happening and how to disable or improve that functionality

Could you edit your first post with a resume of what happened and what you found to let every one who enters to this post meet what happened?