Performance

One of AutomateWoo’s unique characteristics is that it runs entirely on your server. Whether you are automating a follow-up email, abandoned cart recovery, or win back of an inactive customer, the code and data controlling the workflow is within your WordPress site.

From time-to-time, we have customers ask about the performance impact of this native eCommerce automation. Some real questions from our customers:

I’m concerned about site speed – with AutomateWoo running everything directly off my site – will there be a lot of resources used on my server?

And:

How does your plugin affect the speed, page load, server load, cpu, etc of a wordpress website?

We are committed to minimizing the performance impact of AutomateWoo, while maximising the functionality.

We actively take steps to ensure AutomateWoo doesn’t negatively impact a visitor’s experience with your store via slow page loads and that it uses resources on your server to process automated tasks efficiently.

To achieve this, most of AutomateWoo’s functionality runs in the background. This prevents slowing down your site either for your customers or store managers. In fact, the plugin loads almost nothing on the front-end of your store!

We also follow plugin performance best practices, like using well indexed custom database tables to store data and only loading components when they are being needed. We also regularly monitor AutomateWoo’s performance on a number of live sites, including AutomateWooCommerce.com, via the performance monitoring tool New Relic to proactively discover unexpected performance issues.

This all helps ensure that AutomateWoo is a performant plugin.

The rest of this guide provides detailed information about the steps we take in AutomateWoo to have it perform without adversely impacting your site.

Generally speaking, there are a number of metrics that can be used to determine how performant a given WooCommerce plugin or store is:

• Site speed – how quickly will a front end page load for a customer. Example: does a plugin cause the product page to load more slowly for a potential customer?
• Server load – how many hardware resources, including CPU, memory, and hard disk I/O, are required for the plugin to run. Example: how much CPU does a given plugin use per hour?
• Plugin Conflicts – will this plugin’s operations cause other plugins to perform operations more slowly? Example: how many renewals / hour can WooCommerce Subscriptions process when AutomateWoo is processing a large number of workflows?
• Processing Rate: how many operations can the plugin perform in a given time period? Example: how many workflows can AutomateWoo process per hour?

Similarly, there are a number of potential ways a site can grow in relation to its use of AutomateWoo, all of which we’ve seen customers express concern about:

• Large Number of Workflows: will having a large number of workflows, like 300 or more, slow down a store?
• Large Number of Rules: does having a large number of rules on a workflow cause a workflow to be processed slowly (or not at all)?
• Large Number of Actions: does having a large number of actions on a workflow cause a workflow to be processed slowly (or not at all)?
• Large Order and/or Subscription Counts: how well does AutomateWoo work on a store with millions of orders or hundreds of thousands of subscriptions?

Page load is critical to an eCommerce store’s success. Your store’s page load times are something AutomateWoo should never adversely impact.

AutomateWoo avoids slowing down page load times by running almost all of its operations in background requests that are separate to the requests by visitors and potential customers on your site. This background processing, discussed later in more details, is the key to not slowing down page loads.

Poorly implemented background processing can still adversely impact a site. If a plugin consumes too many PHP processes or other server resources, then front-end, uncached page requests can be impacted. AutomateWoo’s background processing ensures that no more than 10 PHP processes will ever be used to perform its background processing. Realistically, it will be rare more than two are used, as AutomateWoo allows just one background processor per component, e.g. Abandoned Cart or Worklows.

Note: For best performance, be sure to setup static page caching via a plugin like WP Rocket, or use a host with caching built in, like Pantheon’s Edge Cache. This prevents the WordPress application, including AutomateWoo and all other plugins, being used to serve your site’s content to visitors.

To run effectively, a WooCommerce store needs hardware resources – at least one CPU, memory, and hard disk I/O for files and database. At the core of measuring a plugin’s performance is its utilisation of those resources, and the efficiency of that usage.

To ensure memory and CPU resources are used efficiently, components are only loaded when they are being used and some features such as abandoned cart can be disabled.

To ensure hard disk and database I/O is performant, AutomateWoo stores its data in custom database tables so that queries are efficient and its data remains separate to the WordPress and WooCommerce database tables.

In addition to being efficient, AutomateWoo ensures it does not become a resource hog, and utilise so many resources on the server that other plugins or requests are able to run. It does this by processing most functions in batches with conservative limits on the amount of memory and time that can be consumed by that processes.

To run workflows and other functions, AutomateWoo does need to use server resources more often than the average WordPress plugin. Especially on sites with a large number of workflows, orders, or workflows using certain rules.

If you use New Relic for performance monitoring, it is not uncommon to see AutomateWoo as one of the Most Time Consuming plugins. This is not an indication AutomateWoo is not performant. It is an outcome of the work AutomateWoo is doing on your site.

WooCommerce stores can have many different plugins from different authors running on the site. To maintain the store’s performance, it’s important each of these plugins be designed to “play nice” with others.

To do this, AutomateWoo enforces a number of restrictions on its background processing, and also takes particular approaches to how it processes background tasks.

Firstly, AutomateWoo processes its functions in its own background processes. These can be initiated by the shared WP Cron system on the site, but to avoid slowing down other plugins, AutomateWoo will initiate a new request after being triggered by WP Cron, and complete its processing there, rather than consuming time and other scarce resources on the WP Cron request. This ensures that other plugins using the WP Cron system, like Memberships or Subscriptions, will be able to perform their functions well alongside AutomateWoo.

In addition, AutomateWoo will only ever consume one PHP process for handling workflows. This ensures there are PHP workers available for other plugins that may also be performing background processing. Because AutomateWoo also works within conservative limits on the amount of memory and time that can be consumed by that processes, it will not prevent those resources being available to other plugins.

As AutomateWoo will use a single PHP process for handling workflows, and another single process for handling the queue of actions to perform for each workflow, having a large number of workflows will not use a substantially larger amount of server resources at any given point in time compared to performance of a workflow on a site with a small number of workflows.

Regardless of the number of workflows, AutomateWoo will not slow down non-Automatewoo related functions of your site.

More workflows can slow down the rate at which other workflows will be processed, because there will be more work to be done by AutomateWoo. This can be mitigated by modifying the queue defaults to increase the batch size.

Most rules are very light weight and don’t need to execute any database queries, which is the time when there is potential for an impact on performance.

However there are a few that do run queries or api calls:

• Customer’s Active Memberships Plans
• Customer Is Subscribed To MailChimp List?
• Customer Has Active Subscription?
• Customer’s Purchased Categories – All Time
• Customer’s Purchased Products – All Time
• Order Subscription Payment Retry Count
• Customer’s Current Order Statuses
• Customer Review Count
• Order Item Categories
• Cart Item Categories
• Subscription Item Categories

These rules source data from data stores outside of AutomateWoo. Because of this, they can be beholden to the database schema or API response times of these data sources. In particular, querying large sets of Orders based on a meta data is a known bottleneck is both WooCommerce core that is actively being worked on.

Because of that, use of the above rules should be done with careful consideration on stores with more than a few hundred thousand orders in the database.

A workflow’s actions are generally the most resource intensive aspect of a workflow. This is because they perform work, like an API call to send an SMS via Twilio or adding new data to the database on your server when adding a product to a subscription.

AutomateWoo will prevent a queue of workflows running for an extended period of time, but it will not prevent a single workflow from running for an extended period. If you are seeing issues with workflows with a large number of actions, we recommend splitting the workflow into two or more separate workflows.