Slow register? Speeding up the LS Central POS at peak hours

Troubleshooting · 8 min read

Every register feels fast at 9 a.m. with one customer in the store. The complaint that matters is the Saturday one: lineups building while the POS thinks between scans. "The POS is slow" is not one problem — it is at least four different problems wearing the same coat, and each has a different fix. This triage order comes from hands-on LS Central POS troubleshooting work — terminals, menus, and tenant configuration — and every setting and threshold in it traces to LS Retail's own documentation. Work it in order; don't start by buying hardware.

First, split the symptom

Before changing anything, answer three questions. They take two minutes and they decide which lever below is yours:

Write down what you observe, with times. "Slow at 12:15, all three registers, item search worst" is a diagnosable statement. "The POS is slow" is a mood.

Lever 1: the POS Buffer update interval

This is the one documented POS-side setting aimed directly at speed. The POS Buffer upd. Interval (min) field sets how often the POS updates its Search Index table and flushes and refreshes the POS Buffer. By default, the POS does that update and reload at the start of each new transaction — which means the cost lands exactly where the customer feels it, between transactions, all day. LS Retail's own field help states the trade plainly: updating the Search Index table and POS Buffer less frequently will improve performance and speed up the POS.

How to test it without making a mess:

1. Note the current value before touching it, so you can put it back. (If it is unset, you are on the default: refresh at every transaction start.)
2. Set an interval in minutes instead of per-transaction refresh. Start modest — you are testing, not committing.
3. Run it through a real peak and compare against your notes from the symptom split: is the between-transaction pause shorter? Is item search still finding what cashiers expect?
4. Understand the trade you just made: the Search Index and POS Buffer now refresh on your interval rather than constantly, so very recent changes can take up to that interval to be reflected in what the POS is working from. That is the documented mechanism, and it is why you test at a modest interval instead of setting the largest number the field accepts.

What success looks like: the pause at transaction start shrinks at peak, and cashiers report no stale-search surprises during the test window. If search results go stale in ways that hurt, your interval is too long — back it off; the setting is a dial, not a switch.

Lever 2: network latency at peak

For an online POS, the network is part of the register. LS Retail's POS requirements repeat Microsoft's guidance: Business Central is designed for networks with a latency of 250–300 milliseconds or less, measured from the browser client to the Azure data center hosting the app, and Microsoft recommends choosing a network with lower latency because the interface performs better when latency is low. Typical scenarios also need bandwidth of about 1 MBps or more — and a store at peak is not a "typical scenario" if every terminal, plus the back-office PC, plus customer Wi-Fi, shares one connection.

1. Measure at the bad time, not the quiet time. A latency test at 9 a.m. proves nothing about noon. Test from a register during the rush and compare with your off-peak number; LS Retail suggests testing latency with a tool such as AzureSpeed.com.
2. Compare against the design target. If peak latency is pushing past the 250–300 ms range the system is designed for, you have found a real cause, not a vibe — the POS is waiting on the network between actions.
3. Reduce contention before upgrading anything: peak-hour slowness that tracks the store's busiest internet moments is a sharing problem first. What else is saturating the connection at noon is a question your router can answer better than a new register can.

Lever 3: the terminal itself

The LS Central POS relies heavily on JavaScript in the browser — which means the terminal's own capability is part of POS performance, and an old till PC can be the whole story. LS Retail's requirements give you a measurable check instead of guesswork:

1. Run Speedometer 3.0 (the browser benchmark LS Retail points to) on the slow terminal, and on a register that feels fine if you have one.
2. Compare against the documented warning line: a score below 7 may indicate the device's performance could negatively impact the Business Central web client. A terminal under that line, while others are above it, explains "just this register is slow" better than any setting will.
3. Check the basics the requirements assume: the client should run a current, supported browser, and peripherals connect through the latest version of LS Central Hardware Station. A "slow POS" that is really a slow receipt printer or a lagging scanner shows up here — the cashier experiences the peripheral's delay as the POS hanging.

What success looks like: every register scores at or above the documented comfort line, and the slowest terminal in the store is a deliberate spare, not the one on the main till by accident.

Slowdowns that are not your store's fault

• A version-specific regression. LS Central 28.0's release notes record that the Sales History page became significantly slower after upgrading to Business Central 26.5, due to changes in Value Entry table keys — and that its performance was improved again in that release cycle. Note the scope honestly: that is a back-office page, not register lag. But it teaches the right reflex — if slowness arrived with an upgrade, check the release notes for your version before retuning your store.
• Server memory pressure. LS Retail's own troubleshooting for LS Central connection errors (socket timeouts, aborted connections) names a cause worth stealing for performance work: not enough available memory on the server, producing internal errors. The documented remedy is unglamorous — free memory by closing memory-heavy applications such as browsers and other Business Central services on that machine. On an on-premise setup, a server doing double duty as someone's workstation is a peak-hour problem waiting for noon.
• And the honest limit: if the symptom split says all registers, constant, every action, and latency and terminals check out, the remaining layers — the service tier and the database — are partner/IT territory. Hand over your timed observations; they are worth more than a reinstall. (A terminal that has dropped offline entirely is a different failure — see our offline mode guide.)

What success looks like

• At peak, the pause between finishing one transaction and starting the next is short and consistent across registers — no one till is the "slow one" customers avoid.
• Item search returns at typing speed during the rush, with the buffer interval set to a tested value you can state and justify.
• You have numbers on file: peak vs off-peak latency against the 250–300 ms design target, and a Speedometer score per terminal, all at or above the documented line.
• The next time someone says "the POS is slow," the first response is the three symptom questions — not a settings change.

FAQ

Will raising the POS Buffer update interval break item search? It changes how often the Search Index and POS Buffer refresh — less often means faster, per LS Retail's own field help, but fresher-data lag is the trade. Test a modest interval at peak and judge both effects.

Is a slow register a sign we need new tills? Only if the terminal is the constraint — which the Speedometer check can actually show (below 7 is LS Retail's warning line). Network and settings causes are cheaper to rule out first.

The back office is slow, not the registers. Same fixes? Partly — latency and server memory apply everywhere. But page-specific slowness after an upgrade (like the Sales History case after Business Central 26.5) is a known-issue check, not a store tuning problem.

How much bandwidth does a register need? LS Retail's requirements cite Microsoft's figure of about 1 MBps or more for typical scenarios, with more for high-payload use — the store's total at peak is the number that matters.