Acumatica Performance — Network Latency

A client once described their remote-office Acumatica experience as "every click has a heartbeat delay" — not an error, not a timeout, just a persistent half-second lag on everything. That is the signature of network latency rather than a processing bottleneck, and it needs a completely different diagnostic approach than CPU or SQL tuning, because the servers themselves can be doing nothing wrong at all.

Two latency paths, and they are not the same problem

Acumatica has two network hops that matter for perceived speed: client to app server (browser to IIS, over the internet or a WAN link for remote offices), and app server to SQL Server (usually a fast LAN link, but not always — some deployments split the database onto a separate subnet or, worse, a separate site). A slow client link makes every screen feel sluggish uniformly; a slow app-to-database link makes data-heavy screens disproportionately slower than simple ones. Distinguish them before treating either.

Measure-Command {
  Invoke-Sqlcmd -ServerInstance "SQLPROD\ACU" -Database AcumaticaProd -Query "SELECT 1"
} | Select-Object TotalMilliseconds

Run that from the app server itself. Anything consistently over single-digit milliseconds for a trivial query on a same-site LAN link is worth investigating at the network layer — a saturated switch port, a misconfigured NIC, or an unnecessary hop through a firewall doing deep packet inspection on internal traffic are all things I have found causing this.

Client-side: chattiness beats payload size

For remote-office or work-from-home users on a WAN link, round-trip count matters more than payload size once you are past a few hundred milliseconds of base latency — ten requests at 200ms round-trip cost two seconds regardless of how small each response is. Acumatica screens with heavy tab structures or many linked GI-based widgets on a dashboard generate a lot of small requests. The browser's network tab, sorted by "waterfall" view, shows whether requests are running in parallel (fine) or serialized because one screen's data depends on another's response completing first (the actual latency multiplier).

App-to-database: this is where architecture choices bite

If the app server and SQL Server are not co-located — split across availability zones in a cloud deployment, or across sites for a private-cloud install with a remote DR database — every single query pays that latency, and Acumatica's ORM layer (PXCache-backed BQL) issues many small queries per request rather than one large batched one. A 5ms round trip that is trivial for one query becomes seconds of accumulated latency across a screen that fires eighty queries to populate a complex form with several linked selectors.

The fix is architectural, not a setting: keep the app tier and the database tier in the same availability zone/region, full stop. If cross-region replication is a DR requirement, that is what SQL Server Always On availability groups with asynchronous secondary replicas are for — the app tier should still talk to a synchronous, co-located primary for normal operation.

Measuring instead of guessing

Compare the Request Profiler's SQL time against total request time from both a LAN-connected workstation and a representative remote location for the same operation. If SQL time is identical but total time differs sharply, the gap is client-side network latency. If SQL time itself is elevated regardless of where the browser sits, the app-to-database path is the one to investigate.

Wrapping up

Separate client-latency symptoms from app-to-database latency symptoms before proposing a fix — they have almost nothing in common. Check VPN routing for remote users first since it is the cheapest and most common culprit, and treat app-to-database co-location as a hard architectural constraint, not a tuning knob you can compensate for later.