Acumatica Performance Tuning — The Definitive Guide

Every "Acumatica is slow" ticket I have ever picked up turns out to be one of about six root causes wearing different masks. The instance is not slow in the abstract — a specific screen, a specific report, or a specific integration call is slow, and it is slow because of the app tier, the database tier, or the network between them. This post is the map I use before I open Profiler or SQL Server Management Studio: where to look first, and which of the deeper posts in this series covers the fix once you have found the culprit.

Three tiers, one bottleneck at a time

Acumatica's architecture is a .NET application running under IIS, talking to SQL Server, usually with a load balancer in front of more than one app server in production deployments. Performance work means figuring out which of those three tiers is actually saturated, because tuning the wrong one wastes a day and changes nothing:

• App tier (IIS / w3wp.exe) — CPU-bound business logic, PXCache churn, garbage collection pressure, thread pool starvation under load.
• Database tier (SQL Server) — missing indexes, blocking, parameter sniffing, disk I/O on the data or log files.
• Network / infrastructure — latency between app server and SQL Server, load balancer session affinity, IIS compression settings, connection pool exhaustion.

Ninety percent of the time the symptom (a slow screen) and the cause (a missing index) live in different tiers, which is exactly why guessing wastes time and measuring does not.

The first fifteen minutes

Before reaching for any tool, I run this sequence on every "it's slow" ticket:

1. Reproduce with the Request Profiler (SM205070). It gives you total request time split against SQL time, per-screen, per-user. If SQL time dominates, you are database-bound. If the gap between SQL time and total time is large, you are app-tier or network bound.
2. Check Windows Performance Monitor on the app server for CPU, available memory, and ASP.NET Applications\Requests Queued. A nonzero queue means the app pool cannot keep up with incoming requests — a capacity problem, not necessarily a code problem.
3. Check SQL Server's Activity Monitor or Query Store for blocking sessions and the top resource-consuming queries in the relevant window.

That fifteen minutes routes you to one of the deep-dive posts in this series rather than a guess.

What is and is not in your control

On SaaS-hosted Acumatica, you do not control IIS settings, SQL Server configuration, or physical infrastructure — your levers are GI/report design, customization code quality, and working with Acumatica support on capacity questions. On private cloud or on-premises deployments, all three tiers are yours to tune, which is both more powerful and more ways to shoot yourself in the foot. Know which situation you are in before promising a client an index change you cannot actually make.

The rest of this series

The posts linked from this one each take one tier or one specific symptom and go deep: CPU profiling on the app server, connection pool sizing, IIS compression and output caching, SQL Server indexing patterns specific to Acumatica's schema, diagnosing a single slow GI or report, and the honest story on things Acumatica does not natively do — sharding the database, or wiring in Redis or Elasticsearch. Start here, measure, then go to the specific post that matches what you found.

Wrapping up

Performance tuning in Acumatica rewards a boring, disciplined process far more than it rewards expertise in any one tool: reproduce, measure with the Request Profiler and Query Store, isolate the tier, change one variable, remeasure. Everything else in this series is detail underneath that loop.