# Sync Performance

To set how hard a till works your server:

1. Open **Store health** from the pulse icon at the foot of the menu.
2. Tap **Performance**.
3. Leave **Balanced** selected: it is the default. If your server regularly struggles, and the pace line often reads **Easing off** or **Paused until …**, tap **Eco** instead.

The setting is saved on this device only, for the store it is on, so set each till. The presets are compared in [What syncing costs your server](#request-budgets).

## Understand the Performance messages[​](#troubleshooting "Direkter Link zu Understand the Performance messages")

Four things the Performance tab can show. The first two need action; the last two are normal.

Easing off or Paused until … most days — choose Eco, then check your server

Your server is regularly turning the till away, returning errors or answering slowly, and the [pace line](#server-pressure) says which. Choose **Eco** on each till, and see [Server Performance](/de/troubleshooting/performance/slow-server.md) for hosting, plugin, firewall and slow-response checks.

⚠ Needs attention — check this till's connection and sync jobs

The till is offline, sync is blocked, a first download failed, or a sync job's last run failed. See [Store health](/de/troubleshooting/store-health.md#performance).

Your server doesn't report its load — the other readings still work

Nothing is wrong. The pace and the request counts still work.

0.0 MB next to many requests — sizes your server doesn't state count as 0

Your server doesn't state the size of its answers, so they count as 0. See [What the numbers don't tell you](#honest-limits).

## The Performance tab, and what sits behind it[​](#performance-tab "Direkter Link zu The Performance tab, and what sits behind it")

![Store health's Performance tab: the status line with the last 24 hours, the Engine uptime strip, the Eco, Balanced and Realtime presets, the Check for changes and Records per request sliders, and the Right now line](/img/2.x/support/store-health/en/tablet-light-regular--sh-5-performance.png)12345678

1. **Last 24 h** — every request this till made for this store, the data it received and its typical response time. The data figure is a floor: see [What the numbers don't tell you](#honest-limits).
2. **Engine uptime** — one cell per hour. Amber means at least one request failed that hour, which also feeds [backing off](#server-pressure).
3. **Eco** — a check every 5 minutes, 25 records per request. See [What syncing costs your server](#request-budgets).
4. **Balanced** — a check every 60 seconds, 50 records per request. The default.
5. **Realtime** — a check every 10 seconds, 75 records per request.
6. **Check for changes** — how often the till asks what changed, 5 seconds to 5 minutes.
7. **Records per request** — how heavy each download page is, 10 to 100. This is usually what costs a shared server most: see [Page weight](#page-weight).
8. **Right now** — the next check, and about how many requests an hour the settings make. The figure is an estimate: see [The requests-per-hour figure](#nominal-rate).

## What syncing costs your server[​](#request-budgets "Direkter Link zu What syncing costs your server")

Two settings set the steady cost: how often the till checks, and how many records it fetches per request.

* **Eco** — choose it when your server regularly struggles. A check every 5 minutes, 25 records per request.
* **Balanced** (the default) — choose it for most stores. A check every 60 seconds, 50 records per request.
* **Realtime** — choose it for the fastest updates, if your server has room to spare. A check every 10 seconds, 75 records per request.
* **Custom** — choose it to set the two sliders yourself.

Checks an hour, and the Custom ranges

**Eco** makes 12 checks an hour, **Balanced** 60 and **Realtime** 360, the most work for your server. **Custom** checks every 5 seconds to 5 minutes, in 5-second steps, with 10 to 100 records per request, in steps of 5: from 720 checks an hour down to 12.

Moving either slider makes the setting **Custom**; **Reset to Balanced** puts the default back.

### Page weight[​](#page-weight "Direkter Link zu Page weight")

Records per request decides how much work each download is for your server. A page of 100 products can take seconds even on a fast server, and the check interval only multiplies that. So each preset moves both settings together, and no preset uses the 100-record maximum: it is there in **Custom** for servers you know can take it.

### What keeps a quiet store cheap[​](#cheap-checks "Direkter Link zu What keeps a quiet store cheap")

A store where nothing changed costs little to keep in sync: its answers are empty, the tills' checks are spread out, and on fast settings a till nobody is using checks less often.

Empty answers, spread checks and idle tills, in detail

* **An unchanged store answers with an empty reply.** The till sends what it last saw, and the server replies `304 Not Modified` with no body. It still counts as one request.
* **Checks are spread out.** Each wait is between 80% and 120% of your setting, so several tills don't all ask at the same moment. That's why the **Right now** countdown is rarely exactly your setting.
* **A till nobody is using slows down,** on settings faster than a minute. After 10 minutes with no tap, key press or barcode scan, it steps to a check every 30 seconds, then every 60 seconds. A hidden app goes straight to 60 seconds. Any use brings it back and checks at once, unless your server has slowed the till down. **Balanced** and **Eco** are already at a minute or slower, so they don't change.

### Background maintenance[​](#maintenance-budgets "Direkter Link zu Background maintenance")

On top of the change checks, a few background jobs keep the till's copy complete and honest: they find records deleted on the server, and fill in what a till hasn't downloaded yet, so it can sell offline. Each run has a fixed ceiling: at most 11 requests, and the top-ups make 1.

Open orders are checked too. When the till starts, and every 5 minutes after, it asks your server about each [open order](/de/sell/cart/open-orders.md) it holds that is already saved there, at most **Records per request** orders to a request. An open order someone trashed or deleted in WP Admin then leaves the till; one with changes not yet sent to your server stays.

Every background job and its ceiling

| Job                                                                        | Runs about every | Most requests per run                              |
| -------------------------------------------------------------------------- | ---------------- | -------------------------------------------------- |
| Deletion audit                                                             | 17 min           | 11                                                 |
| Deletion audit, till already in step                                       | 17 min           | summary pages only (at most 9), no detail requests |
| Fingerprints for records already on the till (100 IDs a request)           | 15 min           | 5                                                  |
| Product top-up, one page in the order the product list is sorted           | 5 min            | 1                                                  |
| Customer top-up                                                            | 5 min            | 1                                                  |
| Variation download                                                         | 5 min            | 1                                                  |
| Server totals for Store health (one count per request, fetched when stale) | 30 s checks      | 11                                                 |

How the deletion audit stays inside 11 requests

The audit compares the till's records with the server in buckets. It reads at most 9 summary pages (3 for each kind of record it checks), and skips every bucket whose summary matches. Only a bucket that differs gets a detail request, and at most 2 of those per run. If there is more to check, the audit saves its place and carries on next run, rather than catching up in one burst. Under server pressure a run drops to 1 summary page per kind and 1 detail request.

### The requests-per-hour figure[​](#nominal-rate "Direkter Link zu The requests-per-hour figure")

**At these settings: \~N requests per hour** estimates how often this till checks for changes, worked out from **Check for changes** alone. It isn't a limit on all requests. The **last 24 h** count at the top of the tab is the real total.

Why the real count differs

Spreading moves the real count either way, a `304` still counts, an idle till on a fast setting asks less, and your server slowing the till down asks less again. Background maintenance and the cashier's own requests (searches, saving orders) come on top.

## Four rules the engine follows[​](#the-four-rules "Direkter Link zu Four rules the engine follows")

The costs above, and the slowdown below, come from four rules: cost follows what changed, background work has a ceiling, the cashier comes first, and under pressure background work gives way first.

How each rule works

Every till keeps checking your store for changes, so the POS treats your server's time as something to spend carefully. The rest of this page gives the numbers behind these rules, for store owners and developers; for a walk through the whole tab, see [Store health › Performance](/de/troubleshooting/store-health.md#performance).

1. **Cost follows what changed, not how big your catalogue is.** Every check starts with a cheap question, and an unchanged store answers it with an empty reply. An unchanged 50,000-product store costs about the same to keep in sync as an unchanged 500-product store.
2. **Background work has a ceiling.** Every background maintenance job declares the most requests it may make in one run, and the engine's tests fail if it makes more. Bigger jobs run in small batches and pick up where they left off next time.
3. **The cashier comes first.** The requests that make a till ready to sell run first. Audits wait until the first page of products has downloaded, then a further minute. While the app is hidden or in the background, maintenance waits.
4. **Under pressure, background work gives way first.** When your server struggles, the till checks for changes less often and puts off maintenance. Searches, barcode lookups and saving a sale are never held back.

Why your server's time is precious

Most stores run on shared hosting, where each request from a till starts WordPress from scratch, competes with your website's own visitors, and can trip a security plugin's rate limit. Every till adds its own checks on top.

## Backing off when your server struggles[​](#server-pressure "Direkter Link zu Backing off when your server struggles")

Every answer the till gets feeds a pressure check, one per website on this device. When it trips, the pace line under **Your server, over time** says so, with the reason. If **Easing off** or **Paused until …** shows most days, see [Understand the Performance messages](#troubleshooting).

![Your server, over time: the pace line reading Normal pace, your server reports high load, the Server load and POS requests charts, both still filling in, and the Learn more in the docs link](/img/2.x/reference/sync-performance/en/tablet-light-regular--sp-2-server-over-time.png)1234

1. **Pace** — what the till is doing about your server, shown close up below.
2. **Server load** — the load your server reports, everything running on it and not just the POS. A server that doesn't send it shows **Your server doesn't report its load**, and the rest of the tab still works.
3. **POS requests** — this till's requests, hour by hour, for the last 24 hours. Both charts read **Not enough data yet** until the till has run for a while, as here.
4. **Learn more in the docs** — opens [Store health › Performance](/de/troubleshooting/store-health.md#performance) in the docs.

![Close-up of Your server, over time: the pace line reading Normal pace, your server reports high load; the till only slows down if its answers do](/img/2.x/reference/sync-performance/en/tablet-light-regular--sp-3-pace-line.png)1

1. **Pace line** — **Normal pace**: leave your setting as it is. Your server reports high load but still answers quickly.

When the till does slow down, the pace line names the reason. **Easing off — checking 2× less often** is followed by one of these, and the number grows with each step:

* **… your server asked the POS to slow down** — your server turned a request away as one too many.
* **… your server returned errors** — several requests failed on the server within a minute.
* **… requests to your server timed out** — several requests got no answer in time.
* **… your server was answering slowly** — typical answers are taking more than 2 seconds.
* **… your server reported high load** — most recent answers came marked as under high load, or the load your server reports has doubled.

**Paused until … — your server asked the POS to wait** means your server refused a request and said when to try again. The till waits as asked, up to 15 minutes.

Errors while the device is offline don't count: that's your connection, not your server.

Exactly what trips each pace line

| Pace line ends             | Your server                                                    | The till reacts                                                  |
| -------------------------- | -------------------------------------------------------------- | ---------------------------------------------------------------- |
| asked the POS to slow down | answers `429 Too Many Requests`                                | at once                                                          |
| returned errors            | returns `5xx` errors                                           | after 3 within a minute                                          |
| requests … timed out       | doesn't answer in time                                         | after 3 within a minute                                          |
| was answering slowly       | answers slowly                                                 | when the middle of the last 10 response times is above 2 seconds |
| reported high load         | marks its answers `X-WCPOS-Pressure: high`                     | on about 6 of the last 10                                        |
| reported high load         | reports a load at least twice its usual level (and at least 1) | after 2 readings in a row, 2× at most                            |
| Paused until …             | sends `Retry-After` with a refusal                             | at once, for up to 15 minutes                                    |

A server that marks its answers `elevated` or `high` but still answers quickly shows **Normal pace — your server reports high load; the till only slows down if its answers do**, as in the close-up above (or **elevated load** at the lower level). The header can start a slowdown but never keep one going on its own: the till trusts how fast your server actually answers.

### What slowing down means[​](#back-off-steps "Direkter Link zu What slowing down means")

* **The till checks for changes less often.** Each step doubles the wait between checks. How far it can slow depends on your setting: to about 5 minutes on **Balanced** and **Realtime**, and to 10 minutes on **Eco**. Custom settings and pauses are in the details below.
* **Background maintenance waits.** A job that has waited a long time still does one small run, unless your server has asked the POS to wait.
* **The POS doesn't hold back what the cashier does.** Searches, barcode lookups, opening a record and saving a sale are never held back by the slowdown, though a struggling server may still answer them slowly.

How far each setting slows, and which maintenance still runs

* **Each step doubles the wait between checks,** up to about 5 minutes: **Realtime** can slow 32×, **Balanced** 8×, and **Eco** 2× (to 10 minutes). A custom setting slows to 5 minutes, or to twice its own interval if that is longer. A `Retry-After` pause can run past those limits, up to its 15 minutes.
* **Background maintenance waits.** The [background jobs](#maintenance-budgets) hold off. A job that has waited twice its usual interval (the deletion audit and the fingerprint job, once) does one run anyway, within its ceiling, unless your server has asked the POS to wait. The deletion audit's run is cut to 1 summary page per kind of record and 1 detail request.

### Coming back up[​](#recovery "Direkter Link zu Coming back up")

Once your server answers normally again, the till works its way back to your setting by itself, one step at a time (high load your server reports has its own rule, in the details below). You don't need to change anything. Slowing down is instant; speeding up is gradual, so a shaky server isn't bounced between fast and slow.

Presets, store switches, restarts and server load

* **Each step back up takes 10 healthy answers in a row,** and only once a minute has passed since the till last slowed down and no `Retry-After` pause is running. From 32× it takes 50 healthy answers to get back to your setting.
* **Changing preset keeps the slowdown,** cut down to the new preset's limit. You can't switch it off: it runs under every preset, including **Custom**.
* **Switching store or cashier on the same website keeps it.** Each website on the device has its own.
* **Closing the app resets it.** The till starts at your setting and slows again if your server is still struggling.
* **Server load works on its own.** When the load your server reports reaches twice its usual level (and at least 1) on two readings, the till checks half as often, until two readings fall back under 1.25 times its usual level.

## Staying responsive on the till[​](#device-responsiveness "Direkter Link zu Staying responsive on the till")

Background sync must never make the screen stutter. Audits work in short chunks and pause so the screen can respond. In the engine's tests, the first results of a list still arrive in well under a tenth of a second while an audit runs. And when the database can filter and sort a list itself, only the rows on screen leave it.

The measured figures

* **Audits pause to let the screen respond.** The deletion audit works in chunks, and no chunk runs longer than about **30 ms**, well under the 100 ms where people notice lag. With 10,000 products on the till, a whole audit takes about **68 ms** of work, spread over 17 or 18 pauses. With 50,000 products, under 300 ms.
* **The first result stays quick while sync runs.** The first results of a query still arrive in about **7–10 ms** while a 10,000-product audit runs, and about **40–54 ms** during a 50,000-product audit.
* **Only the rows you can see leave the database,** when the filter and sort can run inside it, so a screen update moves ten rows, not ten thousand. Searches, and filters the database can't run itself, are worked out on the till instead.

These figures come from the engine's performance tests, measured on one computer with the database in memory.

How these figures are measured

The tests run on an Apple silicon computer with the database in memory, and on their own in CI whenever the sync engine changes. Their limits sit about 11–18 times above the measured figures (3 times for the 30 ms chunk), and three times higher again in CI, so they catch a slowdown of that size, not a slow test machine.

## Checked against a live store[​](#live-verification "Direkter Link zu Checked against a live store")

The rules above are also checked on a real WordPress store, by hand, after a release is deployed: the till makes **no** audit requests before the product list first shows, and stays inside the audit's ceilings after that.

What the live test checks, and why it exists

The test reloads the POS with an audit due and checks that:

* the till makes **no** audit requests before the product list first shows, and
* after the minute's hold, the audit makes at most **9** summary pages and **2** detail requests.

The test came from a real regression: an early development build sent **41** detail requests (**1.2 MB**) in one audit when a till rebuilt its records. The design that replaced it checks summaries first and keeps detail requests under the ceilings above, and the engine's tests enforce those ceilings on every change.

## What the numbers don't tell you[​](#honest-limits "Direkter Link zu What the numbers don't tell you")

* **How long a first download takes.** That depends almost entirely on your server's response times and your catalogue size. In the tests, writing 10,000 downloaded products into the till's database takes under 10 ms; the network and the server take the rest.
* **How much faster than WCPOS 1.x this is.** The two designs differ too much for one number to be fair. [How the Sync Engine Works](/de/developers/sync-engine.md) lays out how they differ.
* **What your own store will see.** The test figures come from one computer with the database in memory. That's why the Performance tab shows what this till actually did in the last 24 hours rather than a forecast. Its data figure counts only answers that state their size, so it can read lower than the real traffic, even **0.0 MB**.

## Related Documentation[​](#related-documentation "Direkter Link zu Related Documentation")

[Store HealthChange the sync settings on a till, and read what it is doing.](/de/troubleshooting/store-health.md)

[How the Sync Engine WorksHow changes reach the till and your store.](/de/developers/sync-engine.md)

[Server PerformanceWhen your hosting struggles to keep up.](/de/troubleshooting/performance/slow-server.md)