Business Central performance tuning, measured before it is fixed

The slowdowns that call for Business Central performance tuning

Complaints rarely arrive as a clean diagnosis. People say the sales order page takes a long while to open. Or posting a large journal freezes the screen. Or everything crawls at a certain time of day. Sometimes the message is sharper. A lock timeout error tells a user that another session holds the table.

Each of those points to a different kind of cause. A slow page often means too many calculated fields or a heavy factbox. A slow posting usually means code running inside the transaction. Slowness at a fixed time usually means a scheduled job. Sorting complaints into these groups is the first step.

Measuring with telemetry and the performance profiler

Business Central can send telemetry to Azure Application Insights. Once it is connected, the service records long-running queries and long-running AL methods. It also records lock timeouts, report run times and web service calls. Each one shows the object and extension responsible. We query that data to rank what costs users the most time.

For a single slow action, the in-client Performance Profiler is quicker. A user starts a recording and repeats the slow step. The profiler then shows where the time went, split by extension and by method. It often names one event subscriber in a single app as the whole problem.

Business Central performance tuning in your extensions

Custom code is the most common cause we find. Typical faults are loops that read one record at a time when a single filtered query would do. Another is calculated fields that run on every row of a long list. A third is event subscribers that run costly logic on every validation, needed or not.

The fixes are well known. Load only the fields the code uses. Add keys that match the filters. Replace repeated lookups with set-based work. Move work that need not block the user into a background task or a job queue entry. Keep transactions short, so locks are held briefly.

Tuning through configuration and scheduling

Not every gain needs a developer. You can move job queue entries for cost adjustment, planning or integrations away from peak working periods. You can also stop them from overlapping. Heavy reports can run on a schedule into the Report Inbox, not interactively. Analytical reads can use the read-only replica.

Page design matters too. Removing unused factboxes and columns from a busy list makes it lighter for everyone in that role. Integrations deserve the same attention. A connector that polls too often, or pulls whole tables, can slow the system for the people working in it.

What Business Central performance tuning delivers

You receive a ranked list of findings. Each has the evidence behind it, the fix and the owner. Where the cause is in our reach, in your own extensions or setup, we make the change in a sandbox. Then we measure again and deploy it.

Where the cause sits in a third-party app, we document it with profiler output so the publisher can act on it. We stay honest about limits. In the cloud, Microsoft runs the hardware and the database. So tuning is about what your tenant asks of the service, not about server settings.

Business Central performance tuning questions

Why did Business Central performance drop after an extension was installed?

Extensions subscribe to events in standard code. So a new app can add work to every posting or every page open. The Performance Profiler shows time per extension. That makes it simple to confirm whether the new app is responsible. Then we talk to the publisher with proof in hand, or we change your own code if the extension is yours.

Can Business Central performance tuning add server power online?

No. Microsoft manages capacity for the online service, and there is no setting for it. You improve performance by reducing what your code, jobs and integrations demand. That is where Business Central performance tuning belongs. It is good news, since those are things you control. We show you which ones matter most.

What causes lock timeout errors?

Two sessions want to change the same table. One waits too long for the other to finish. Long transactions, poorly timed jobs and code that locks early are the usual reasons. Telemetry records which object held the lock. So we can name the cause, then shorten the transaction or move the job, and run the test again.

Do we need Application Insights to tune performance?

It is not strictly required, since the profiler works without it. Even so, it is the only way to see patterns across all users over time. It is an Azure resource that Azure bills by data volume. Connecting it is a short task. We help you set it up, and we explain what data it collects.

Does a large database slow the system down?

Size alone matters less than how data is read. Well-indexed queries stay quick on big tables. That said, clearing out old logs and archived documents keeps storage and some operations leaner. Compressing old entries can also help, where it suits your audit needs. We check your largest tables first, and we tell you what is safe to clean.

Related technical services

Tuning often leads into neighboring work, such as a broader look at the system, cleaner extension code or better monitoring. These pages describe those services and when each one applies. Read them next if your Business Central performance tuning shows problems that reach beyond one slow page, so the fixes hold and stay measured. For the product detail, see Microsoft Learn: performance overview for Business Central.