---
title: Performance
date: 2026-07-03T12:37:00+01:00
author: John Henry Donovan
canonical_url: "https://johnhenry.ie/plugins/order-lifecycle/docs/getting-started/performance"
section: Plugins
---
esc

↑↓ to navigate↵ to selectesc to close

Menu On this page 

- [Return to top](#)

Documentation

Documentation

# Performance

Order Lifecycle logs events synchronously by default, inside the same request as the order save. On a low-to-medium volume store you won't notice it. On a high-traffic store - flash sales, lots of concurrent checkouts, large carts - the defaults can add measurable latency to checkout. This page explains why, and what to change before going live on a busy store.

## Why the default can add latency

Craft Commerce saves an order multiple times during a single checkout as it recalculates totals, applies adjustments, and processes payment. Order Lifecycle listens to each of those saves and logs any event category that changed. With default settings, each individual log entry does one read (to diff against the previous snapshot) and one write - both run inline, inside the checkout request.

The main amplification point is **line item quantity changes**: each changed SKU in the cart gets logged as its own event. A cart with a lot of line items being edited in one save can generate a correspondingly large number of reads and writes in that single request, all before the response gets back to the customer.

None of this touches Commerce's own order data or slows down payment processing itself - it adds to total request time, not payment reliability.

## What to change before going live

### 1. Enable Async Queue Logging (do this first)

**Settings → Order Lifecycle → General → Async Queue Logging**, or via config:

```php
// config/order-lifecycle.php
return [
    '*' => [
        'asyncLogging' => true,
    ],
];
```

This moves the database write for every log entry onto the Craft queue instead of the request. The change-detection read still happens inline (it has to, to build the log message), but the write - the more expensive half - gets deferred. This is the single biggest lever you have for reducing checkout latency from this plugin.

**Requirements:**

- A queue worker needs to be running continuously (`php craft queue/listen`, or a supervisor/systemd process, or Craft Cloud's managed queue). If the queue isn't processed, logs pile up as pending jobs rather than being lost, but they won't show up in the timeline until the worker catches up.
- Don't enable this in local development if you're not running a queue worker there - logs will look like they're missing until you manually run `php craft queue/run`.

### 2. Turn off event categories you don't need

Every enabled category in **Settings → Order Lifecycle → Logging** is a potential write per relevant order save. If you don't need line-item-level granularity in the timeline, turning it off removes the biggest single source of per-order write volume:

SettingRecommendation for busy storesLog Line Item ChangesConsider disabling if you don't need per-SKU quantity-change history - this is the highest-volume categoryLog All Payment TransactionsLeave off (default) unless actively debugging a gateway - this logs every individual transaction state changeLog Payment AttemptsKeep on unless payment retries are extremely frequent for your gateway

Categories tied to one-time events per order (status changes, order complete, order paid, coupon changes) are cheap no matter the store size - they fire once per order, not once per save.

### 3. Auto-prune, don't let logs grow unbounded

A busy store generates a lot of log rows. Set **Auto-Prune Logs After (Days)** to a retention window that suits you (90-180 days is a reasonable default for most stores), so the table doesn't grow forever and export/report queries stay fast. See [Log Pruning](https://johnhenry.ie/plugins/order-lifecycle/docs/getting-started/configuration).

### 4. AI Insights are already safe by default

The Anthropic AI features never run on the customer-facing checkout path - per-order insights only run from an admin-permissioned CP action, and store-wide insights run on the queue. Nothing to do here; it's just worth mentioning, since it's a fair question to ask when you're weighing up an AI-integrated plugin for a live store.

## What this plugin does not do

- It doesn't delete, modify, or lock any Commerce order, address, user, or transaction data - only its own `orderlifecycle_logs` table.
- It doesn't block or delay payment gateway calls - logging happens around Commerce's own save/payment events, not inside them.
- It doesn't make outbound HTTP calls (to Anthropic or otherwise) during a customer-facing request.

## Recommended baseline for a busy store

```php
// config/order-lifecycle.php
return [
    '*' => [
        'asyncLogging' => true,
        'autoPruneLogs' => 120,
    ],
];
```

Combined with a running queue worker, this keeps every database write for lifecycle logging well away from the checkout response path.

## See Also

- [Configuration](https://johnhenry.ie/plugins/order-lifecycle/docs/getting-started/configuration) - Full settings reference
- [Event Tracking](https://johnhenry.ie/plugins/order-lifecycle/docs/guide/event-tracking) - What each event category records

On this page