A slow page is a symptom. Find the layer that owns it.

Most performance investigations start with a sentence, not a measurement. "The sales order page takes forever." "Posting is slow again." Each is a true report of a real experience, and each describes where the pain is felt, not where it comes from. A user sees one page. Underneath that page sit the AL code and extensions that run when it opens, the service tier that executes them, the SQL statements they send, the locks those statements wait on, the storage and network beneath the database, and any integration the page calls on the way.

Every one of those layers can produce exactly the same sentence. That is why the most common response, adding compute, so often changes nothing: if the time is spent waiting on a lock, or on a query whose plan went bad last Tuesday, a bigger server is an expensive way to wait.

Each layer leaves a different trace

The useful news is that Business Central already reports most of what you need, if telemetry is switched on. The platform sends signals to Azure Application Insights, and several of them map directly onto the layers in the film:

• Page views (event CL0001) tell you which page the user actually opened, so a complaint can be tied to an object instead of a feeling.
• Long-running SQL queries (RT0005) are logged as warnings when a statement exceeds a threshold, with the statement's execution time and the AL object that issued it. On-premises, the threshold is a server setting you can change.
• Long-running AL methods (RT0018) record operations that exceeded a time threshold, including the time spent excluding waits on the client. On-premises this needs to be configured on the server instance; online, the service enables it case by case.
• Database lock timeouts (RT0012) and the deadlock signal show when the time went on waiting for another session rather than doing work.
• Database wait statistics telemetry, available from version 20, shows which wait types delayed queries, which points at the resource or operation responsible.

On the SQL Server side, Query Store keeps a history of queries, their plans and their runtime statistics, separated into time windows, so you can see whether a query got slower because its plan changed. It is on by default for new Azure SQL databases and for new databases from SQL Server 2022; on SQL Server 2016 to 2019 someone has to turn it on.

Read the traces in order

The order matters more than the tooling. In our practice, the investigation that ends quickly is the one that narrows before it digs:

• Start from the page and the time. Which page, which company, which user, at what time of day? A complaint that happens only at month-end is a different problem from one that happens every morning.
• Ask whether the time was spent in AL or in SQL. If long-running AL methods appear without long-running SQL, look at the code path: loops, repeated calls, work done per record that could be done once.
• If SQL owns it, ask whether it was working or waiting. A long statement with lock timeouts or blocking around it is a concurrency problem; a long statement alone is usually a plan, an index or a data-volume problem.
• If neither owns it, look outward: an integration call, a web service, a file exchange or the network between the user and the service tier.

Each step removes most of the stack from the search. That is the point: the cost of an investigation is mostly the layers you look at that turn out to be innocent.

The traps

• Treating the average as the experience. A page that is usually fine and occasionally terrible has a cause that only appears in the bad minutes. Look at the slow occurrences, not the mean.
• Changing two things at once. If a new index and a bigger VM go in the same weekend, nobody will know which helped, and the one that did not will stay forever as cost.
• Assuming the database is guilty because it is the biggest box on the diagram. Sometimes it is. Often the database is simply where the waiting becomes visible.

Five checks for this week

• Confirm telemetry from your environments reaches an Application Insights resource you can query, and that someone has access to it.
• Pick the one page users complain about most and pull its page views and the long-running SQL and AL signals for the same users and times.
• On SQL Server, check whether Query Store is enabled on the Business Central database, and what it is retaining.
• Count lock timeouts and deadlocks over the last month, by time of day. A cluster around a batch job is a scheduling question before it is a tuning one.
• Write down, for that one page, which layer you believe owns the time and what evidence would prove you wrong.

Veltheon is founder-led, based in Ontario, and works on Business Central and NAV, SQL Server and Azure. If one of these sounded like your estate, the first conversation is free and starts with the evidence you already have.