POS running slow: a diagnosis routine for LS Central terminals

Troubleshooting · 9 min read

“The till is slow” is a symptom, not a diagnosis. A slow LS Central POS can be the terminal itself, the network between the terminal and the service, the server and database behind it, or background replication and buffer work competing with the sale. Guessing wastes the Saturday rush. Work the four layers in order, with a documented check at each layer, and the cause usually identifies itself.

Scope the complaint first

Before touching settings, pin down what “slow” means. Microsoft’s performance guidance starts the same way: define and quantify the slow operation, agree what an acceptable time for it is, and measure a baseline before changing anything. Then iterate — measure, locate the bottleneck, eliminate it, and compare against the baseline until the operation is back in line.

Three scoping questions do most of the work:

• One terminal or every terminal? One terminal points at the device or its connection. Every terminal at once points at the network, the service, or the database.
• One operation or everything? A slow item lookup is a different problem from a slow login, a slow tender, or a POS that is sluggish all day.
• Always, or at predictable times? Slowness that arrives on a schedule — opening, price-change mornings, statement time — points at background work rather than hardware.

Write the answers down. They decide which layer below gets checked first, and they are the baseline the fix gets judged against.

Layer 1: the terminal itself

The LS Central POS relies heavily on JavaScript in the web client, so a weak device shows up as a slow POS even when everything behind it is healthy. LS Retail points to Speedometer 3.0 as a way to assess a device and compare scores between devices: run it on a typical terminal from the store, and treat a score below 7 as a warning — LS Retail notes a score under that mark may indicate the device’s performance could negatively affect the Business Central web client.

For terminals that run offline — carrying both the database and the service tier — compare the machine against the documented offline requirements instead of guessing. The resilient offline POS baseline is a Core i5-class CPU with 4–8 GB of RAM and preferably an SSD; the high-volume offline POS baseline is a Core i7 with 16 GB of RAM and an SSD. LS Retail also flags three reasons a terminal may legitimately need more RAM than the baseline: it runs offline with both database and service tier, its database has grown, or other software — anti-virus is the named example — is running alongside the POS. A terminal that was fine two years ago and is slow now, with a much larger local database on it, fits that pattern exactly.

One LS-specific setting belongs in this layer. By default, the POS updates its Search Index table and reloads the POS Buffer at the start of every new transaction. The POS Buffer upd. Interval (min) setting controls how many minutes should pass before that update is attempted — and LS Retail’s own field help states that updating the Search Index table and POS Buffer less frequently will improve performance and speed up the POS. If lookups feel heavy at the start of every transaction while the rest of the system is healthy, this interval is a documented lever, not a hack. Change it deliberately, note the old value, and re-measure.

Layer 2: the network between terminal and service

An online POS is only as fast as its path to the service. Microsoft designs Business Central for networks with latency of 250–300 milliseconds or less, measured from the browser client to the Azure data center hosting the app, and LS Retail recommends testing that latency — AzureSpeed.com or a similar service is the suggested route. Typical Business Central scenarios also need bandwidth of 1 MBps or more, with more required for high-payload scenarios such as rich media or client add-ins.

That gives the network layer two pass/fail checks rather than a vibe:

• Latency check: measure from the affected terminal’s network, not from an office PC on a different connection. Sustained latency above the 250–300 ms design range means the POS will feel slow no matter what is tuned behind it.
• Scope check: if every terminal on the same connection is slow and terminals elsewhere are fine, the shared connection is the suspect — not five terminals failing independently on the same morning.

Do not skip this layer because “the internet works.” A connection can be up, pass a casual browsing test, and still sit outside the latency range the client was designed for.

Layer 3: server and database

When the terminal passes its checks and the network is inside its design range, measure the operation where it actually runs. Business Central ships the tools for this; the routine is knowing which one answers which question.

• Performance Profiler (in-client): the first capture. Open it in the web client, start it, perform the slow operation exactly as the cashier does, then stop it. It records where time was spent, can show which apps and extensions were involved, and can be run by end users, admins, and consultants — no developer required. A profile that shows time concentrated in one app or extension is a completely different conversation from one spread across the base application.
• Page Inspector: for one specific slow page. It shows the extensions affecting the page and the time they took in the call stack, which separates “this page is heavy” from “everything is heavy.”
• Database Missing Indexes: when data retrieval itself is slow, this page lists columns that can be indexed, with information to help optimize retrieval.
• Database Wait Statistics: shows how many queries were delayed, by which wait types, and for how long — the wait types point at the resource or operation responsible for the delay, including locking contention.
• Additional logging (verbose telemetry): from the Help & Support page, for a short repro window only. It captures all SQL queries for the session, which catches the pattern of many individually quick queries adding up — and it slows the system while it runs, so it is a diagnostic window, not a setting to leave on.

The discipline matters more than the tool choice: capture one slow operation cleanly, read where its time went, fix that one thing, and re-measure against the baseline from the scoping step.

Layer 4: replication and background load

The last layer is work the terminal does not control: background jobs, and the buffer and search-index refreshes that run on their own cadence (see Layer 1). A terminal that is only slow when background jobs are running — or a whole store that slows at the same times each day — is not showing a hardware fault. Check what was running at the slow times recorded in the scoping step before replacing anything. If the pattern points at replication work falling behind rather than merely being busy, work the dedicated routine in the Data Director lag guide instead of tuning the POS around it.

The diagnosis routine, in order

1. Scope it. Record which terminals, which operation, and which times. Agree what acceptable looks like for that operation and time it as-is — that timing is the baseline.
2. Score the terminal. Run Speedometer 3.0 on an affected device. Below 7: the device itself is a documented suspect. Compare scores across a slow and a healthy terminal if both exist.
3. Check offline headroom. On offline terminals, compare CPU, RAM, and drive against the documented offline baselines, and account for database growth and other software such as anti-virus.
4. Check the POS Buffer interval. Note the current POS Buffer upd. Interval value. If updates run at every transaction and the pain is at transaction start, trial a less frequent interval and re-measure.
5. Measure latency from the store network. Above the 250–300 ms design range, stop tuning the application — the path is the problem. Confirm bandwidth is at least in the typical 1 MBps-or-more range.
6. Profile one slow operation. Performance Profiler: start, reproduce, stop. Read where the time went — base application, one extension, or data retrieval.
7. Follow the profile into the database pages. Slow retrieval → Database Missing Indexes. Queries waiting → Database Wait Statistics. Many small queries → a short Additional logging window.
8. Correlate with background work. Lay the slow times against replication and job activity. A time pattern that matches job runs is a scheduling or replication problem, not a terminal problem.
9. Fix one layer, re-measure, stop when the baseline is met. Changing three things at once destroys the diagnosis — the next slowdown starts from zero again.

Which layer is it? A decision framework

What success looks like

The routine is done when the scoped operation — the exact one timed in step 1 — runs at or under the agreed acceptable time on the affected terminals, measured the same way as the baseline. The terminal’s Speedometer score and the store’s latency are recorded with the result, so the next “the till is slow” report starts from numbers instead of memory. If a layer’s documented threshold is still breached — latency above the design range, a device under the score warning line — success is an escalation with that measurement attached, not another round of settings changes.

FAQ

Should the POS Buffer interval just be set as high as possible? No. The interval trades freshness for speed: the buffer and Search Index refresh less often. Set it high enough to remove the per-transaction cost, low enough that the data the POS works with stays acceptably current — and judge it by the re-measured baseline, not by feel.

The back-office pages are fast but the POS is slow. Why start at the terminal? Because the POS path adds the device and its JavaScript workload, plus its own buffer behaviour, on top of the shared service. A fast back office rules out some server causes; it says nothing about the terminal layer.

When is it time to involve the partner or support? When the profiler capture shows the time concentrated in code or data structures the store cannot change, or when a documented threshold (device score, latency) is breached and the store cannot fix the underlying device or connection. Bring the baseline, the capture, and the threshold measurement — that package is what makes the escalation short.