Performance articles for developers

In this article, you can read about ways to tune performance when developing for Business Central.

• Writing efficient pages
• Writing efficient Web Services
• Writing efficient reports
• AL performance patterns
• Efficient Data access
• Testing and validating performance
• Tuning the Development Environment
• Using the AL Profiler to analyze performance

Writing efficient pages

There are many patterns that a developer can use to get a page to load faster. Consider the following patterns:

• Avoid unnecessary recalculation
• Do less
• Offloading the UI thread

Pattern - Avoid unnecessary recalculation

To avoid unnecessary recalculation of expensive results, consider caching the data and refresh the cache regularly. Let's say you want to show the top five open sales orders or a VIP customers list on the role center. The content of such a list probably doesn't change significantly every hour. There's no need to calculate that from raw data every time the page is loaded. Instead, create a table that can contain the calculated data and refresh every hour/day using a background job.

Another example of unexpected recalculation is when using query objects. In contrast to using the record API, query results aren't cached in the primary key cache in the Business Central server. Any use of a query object always goes to the database. So, sometimes it's faster to not use a query object.

Pattern - Do less

One way to speed up things is to reduce the amount of work that the system must do. For example, to reduce slowness of role centers, consider how many page parts are needed for the user. Another benefit of a simple page with few UI elements can also be ease of use and navigation.

Remove calculated fields from lists if they aren't needed, especially on larger tables. Setting the field's Enabled or Visible properties to false isn't enough. The field definition needs to be removed from the page or page extension definition. Also, if indexing is inadequate, calculated fields can significantly slow down a list page.

Consider creating dedicated lookup pages instead of the normal pages when adding a lookup (the one that looks like a dropdown) from a field. Default list pages run all triggers and fact boxes even if they aren't shown in the lookup. For example, Business Central 2019 release wave 1 added dedicated lookup pages for Customer, Vendor, and Item to the Base Application.

Pattern - Offloading the UI thread

To get to a responsive UI fast, consider using Page Background Tasks for calculated values, for example, the values shown in cues.

For more information about Page Background Tasks, see Page Background Tasks.

Making Edit-in-Excel faster

The Edit in Excel feature uses UI pages exposed through OData, which means that triggers need to be run for all records returned from the Business Central server to Excel. As a developer, you need to make your AL code conditional on the ClientType. Specifically, avoid updating fact boxes, avoid calculation, and avoid defaulting logic.

Writing efficient Web Services

Business Central supports for Web services to make it easier to integrate with external systems. As a developer, you need to think about performance of web services both seen from the Business Central server (the endpoint) and as seen from the consumer (the client).

Endpoint performance

General anti-patterns (don't do this)

• Avoid using standard UI pages to expose as web service endpoints. Many things, such as fact boxes aren't returned in web service results, but use resources to prepare. Things that have historically caused performance issues on pages that are exposed as endpoints are:

  • Heavy logic in OnAfterGetCurrRecord or OnAfterGetRecord
  • Many SIFT fields
  • FactBoxes

• Avoid exposing calculated fields, because calculated fields are expensive. Try to move them to a separate page or to refactor the code so the value is stored on the physical table (if applicable). Complex types are also a performance hit because they take time to calculate.

• Don't use temp tables as a source if you have many records. Temp tables that are based on APIs are a performance hit. The server has to fetch and insert every record, and there's no caching on data in temp tables. Paging becomes difficult to do in a performant manner. A rule of thumb is if you have more than 100 records, don't use temp tables.

• Don't insert child records belonging to same parent in parallel. This condition causes locks on parent and Integration Record tables because parallel calls try to update the same parent record. The solution is to wait for the first call to finish or use $batch, which will make sure calls get executed one after another.

• Don't use a deprecated protocol such as SOAP. Instead, utilize newer technology stacks such as OData, or preferably API pages/queries. The latter are up to 10 times faster than using the SOAP protocol.

If you’re using codeunits exposed as a web service via SOAP and it is keeping you from migrating to OData, then unbound actions are equivalent to SOAP exposed codeunits in OData. For more information, see Creating and Interacting with an OData V4 Unbound Action.

When reading data from API queries, the use of aggregation methods can affect performance. Don't define this method if you intend to read data on the highest granularity of the underlying table (for example, the entry no. on G/L Entries). While the method property is meaningful for aggregated data, it slows down the performance in context of detailed level queries.

Performance patterns (do this)

• Instead of exposing UI pages as web service endpoints, use the API pages or API queries because they've been optimized for this scenario. Select the highest API version available. Don't use the beta version of the API pages. To read more about API pages, see API Page Type.

• If you do expose UI pages as web service endpoints as web service endpoints, then triggers must be run for all records returned from the Business Central server. As a developer, you must make your AL code conditional on the ClientType. Specifically, avoid updating FactBoxes, avoid calculation, and avoid defaulting logic. For more information, see System.GuiAllowed() Method.

• The choice of protocol (SOAP, OData, or APIs) for the endpoint can have a significant impact on performance. Favor OData version 4 or APIs for the best performance. It's possible to expose procedures in a codeunit as an OData end point using unbound actions. To read more about OData unbound actions, see Creating and Interacting with an OData V4 Unbound Action.

• If you want OData endpoints that work as data readers (like for consumption in Power BI), consider using API queries and set DataAccessIntent = ReadOnly. For more information, see API Query Type and DataAccessIntent Property.

API/OData client performance patterns

When calling APIs and OData web services, there are many strategies that you can use to speed up your queries, like:

• Limiting the set ($filter or $top) if you're using an expensive $expand statement
• Using OData transaction $batch
• Using Data Access Intent Read-only with OData

For more information about OData query performance, see OData Query Performance.

How to handle large throughput of web service calls

When integrating to Business Central from external systems using web services, it's important to understand the operational limits for the Business Central servers that host the web service endpoints being called. To ensure that excessive traffic doesn't cause stability and performance issues for all users, the online version of Business Central server has set up throttling limits on web service endpoints.

Make sure that your external application can handle the three HTTP status codes 429 (Too Many Requests), 503 (Service Temporarily Unavailable), and 504 (Gateway Timeout).

• Handling status codes 429 and 503 requires the client to adopt a retry logic while providing a cool off period. You can apply different strategies, like:

  • Regular interval retry
  • Incremental intervals retry
  • Exponential back-off
  • Randomization

• Handling status code 504 - Gateway Timeout requires the client to refactor the long running request to execute within time limit by splitting the request into multiple requests. Then, deal with potential 429 codes by applying a back off strategy.

A common pattern is to implement a queue in your external application so that you can flatten spikes of traffic. If a request gets the HTTP status code 429 (Too Many Requests) or 503 (Service Temporarily Unavailable), then put it back in the queue and apply one of the retry strategies described previously.

Read more about web service limits, see Working with API limits in Dynamics 365 Business Central.

The same advice applies for outgoing web service calls using the AL module HttpClient. Make sure your AL code can handle slow response times, throttling, and failures in external services that you integrate with.

Performance patterns for business intelligence and reporting

Writing efficient AL reports

Reports generally fall into two categories. They can be specific to a single instance of an entity, like an invoice. Or, they can be of a more analytical nature that joins data from multiple instances of multiple entities. Typically, performance issues in reports lie in the latter category. The following articles contain advice about implementing faster reports:

• Use Read Scale-Out to read data from a read-only copy of the database, see Using Read Scale-Out for Better Performance for more information.
• Use Partial Records to reduce the data loaded from the database, see Using Partial Records for more information.
• Use AL queries to optimize the way data is read from the database, see Queries in Business Central for more information.
• Compared to Word layouts, RDL layouts can result in slower performance with document reports, especially for actions related to the user interface (like sending emails). For more information, see Creating an RDL Layout Report.
• Can you run the report in the background? It will not make it run faster, but the user might feel this way (as they are not blocked in the UI while waiting on the report to finish). For more information, see Schedule a report.

For more information on how to use telemetry to analyze the performance of reports, see Report performance

Stop using report properties DefaultLayout, ExcelLayout, RDLLayout, and WordLayout

Loading data efficiently to Power BI

When calling APIs and OData web services from Power BI, it's important that you understand the concepts of query folding. The Business Central connector uses the OData.Feed library behind the scenes, which translates numerous the Power BI constructs into OData query parameters. For example:

• Table.RemoveColumns or Table.SelectColumns becomes $select
• Table.SelectRows becomes $filter
• Table.ExpandTableColumn becomes $expand

The following example illustrates how filters are pushed from Power BI to the Business Central connector.

It is common practice to have a query that refreshes the current date and time at every refresh in your Power BI dataset:

// LastRefreshDate query
let
    Source = DateTimeZone.UtcNow()
in
    Source

To apply a filter such as “the last 12 months of data” to other queries, simply use the PowerQuery Table.SelectRows on appropriate dates, for example:

// SalesInvoices
// Filtered to last 12 months
let
    Source = Dynamics365BusinessCentral.ApiContentsWithOptions(null, null, null, null),
    PRODUCTION = Source{[Name="PRODUCTION"]}[Data],
    #"CRONUS USA, Inc." = PRODUCTION{[Name="CRONUS USA, Inc."]}[Data],
    v2.0 = #"CRONUS USA, Inc."{[Name="v2.0"]}[Data],
    salesInvoices_table = v2.0{[Name="salesInvoices",Signature="table"]}[Data],
    filteredRows = Table.SelectRows(salesInvoices_table, each [postingDate] > Date.From(Date.AddMonths(LastRefreshDate, -12)))
in
    filteredRows

For a LastRefreshDate of 2022-08-17, the Power BI connector adds this $filter predicate to the API call: /v2.0/PRODUCTION/api/v2.0/salesInvoices?$filter=postingDate gt 2022-08-17&company=CRONUS USA, Inc.

For more information about query folding in Power BI, see Power Query query folding.

For more information about OData/API client performance in Business Central, see OData query performance.

When refreshing a query in a Power BI semantic model, you might experience an error such as DataSource.Error: OData: Unable to read data from the transport connection: existing connection was forcibly closed by the remote host. This error can happen either when the query refresh was interrupted by a transient error (in this case, just implement a retry) or if the query can't finish within the limit defined for web service calls on the Business Central server. In the latter case, the Business Central server will cancel the call. If this happens consistently, you need to tune your query, either by applying data filters, by reducing the number of columns (do you use all of them?), or maybe by partitioning the table (using custom partitioning through the XMLA endpoint for the model).

Efficient extracts to data lakes or data warehouses

When establishing a data lake or a data warehouse, you typically need to do two types of data extraction:

1. A historical load (all data from a given point-in-time)
2. Delta loads (what's changed since the historical load)

The fastest (and least disruptive) way to get a historical load from Business Central online is to get a database export as a BACPAC file (using the Business Central admin center) and restore it in Azure SQL Database or on a SQL Server. For on-premises installations, you can just take a backup of the tenant database.

The fastest (and least disruptive) way to get delta loads from Business Central online is to set up API queries configured with read-scaleout and use the data audit field LastModifiedOn (introduced in version 17.0) on filters.

For more information, see Extract data from Business Central.

AL performance patterns

Knowledge about different AL performance patterns can greatly improve the performance of the code you write. In this section, we describe the following patterns and their impact on performance.

• Use built-in data structures
• Run async (and parallelize)
• Use set-based methods instead of looping

Pattern - Use built-in data structures

AL comes with built-in data structures that have been optimized for performance and server resource consumption. Make sure that you're familiar with them to make your AL code as efficient as possible.

When working with strings, make sure to use the TextBuilder data type and not repeated use of the += operator on a Text variable. General guidance is to use a Text data type if you concatenate fewer than five strings (here the internal allocation of a TextBuilder and the final ToText invocation is more expensive). If you need to concatenate five strings or more or concatenate strings in a loop, then TextBuilder is faster. Also, use a TextBuilder data type instead of BigText when possible. For more information, see TextBuilder Data Type.

If you need a key-value data structure that is optimized for fast lookups, use a Dictionary data type. For more information, see Dictionary Data Type.

Use a List data type if you need an unbound "array" (where you would previously create a temporary table object). For more information, see List Data Type.

Use the Media or Mediaset data types instead of the Blob data type. The Media and MediaSet data types have a couple advantages over the Blob data type when working with images. First of all, a thumbnail version of the image is generated when you save the data. You can use the thumbnail when loading a page and then load the larger image asynchronously using a page background task. Second, data for Media and MediaSet data types is cached on the client. Data for the Blob data type is never cached on the server. It's always fetched from the database.

Pattern - Run async (and parallelize)

It's often desirable to offload AL execution from the UI thread to a background session.

Here are some examples of this performance pattern:

• Don't let the user wait for batches
• Split large tasks into smaller tasks and run them in parallel

There are many different ways to spin up a new session:

• Page Background Task
• StartSession
• TaskScheduler.CreateTask
• Job Queue

They come with different characteristics as described in this table:

Method to start a new asynchronous operation	Characteristics
Page Background Task	Can (will) be canceled Read-only Runs in a child session, which is bound to its parent session. Bound to a page. Lightweight
StartSession	Created immediately Runs on same server as the session that starts it. Runs as a background session. Not as controlled as a Page Background Task
Task	Queued up Any server in a cluster can start it Runs as a background session. Survives server restarts No logging in Business Central.
Job queue	Scheduled Recurrence Any server in a cluster can start it Runs as a scheduled task Survives server restarts Logging of results in Business Central.

Pattern - Use set-based methods instead of looping

The AL methods such as FindSet, CalcFields, CalcSums, and SetAutoCalcFields are examples of set-based operations that are faster than looping over a result set and do the calculation for each row.

• CalcFields, CalcSums, and Count
• FindSet Method

One common use of the CalcSums method is to efficiently calculate totals.

Try to minimize work done in the OnAfterGetRecord trigger code. Common performance coding patterns in this trigger are:

• Avoiding CalcFields calls. Defer them until the end.
• Avoiding CurrPage.Update() calls.
• Avoiding repeated calculations. Move them outside the loop, if possible.
• Avoid changing filters. This pattern requires the server to throw away the result set.
• Never do any database writes here. With more than one user on the system, this gives database locking issues and even deadlock errors.

Consider using a query object if you want to use a set-based coding paradigm. These pros and cons for using query objects:

Pros for using a query object	Cons for using a query object
- Bypasses the AL record API where server reads all fields. - With a covering index, you can get fast read performance for tables with many fields. - Can join multiple tables.	- Query object result sets aren't cached in the servers primary key (data) cache. - No writes are allowed. - You can't add a page on a query object.

Read more about query objects here:

• Using Queries Instead of Record Variables
• Query object
• Query overview
• TopNumberOfRows Property
• Query Objects and Performance

Pattern - Use partial records when looping over data, in reports, or when table extension fields aren't needed

When writing AL code for which the fields needed on a record or recordref are known, you can use the partial records capability to only load out these fields initially. The remaining fields are still accessible, but they'll be loaded as needed.

Partial records improve performance in two major ways. First, they limit the fields that need to be loaded from the database. Loading more fields leads to more data being read, sent over the connection, and created on the record. Second, partial records limit the number of table extensions that need to be joined.

The performance gains compound when looping over many records, because both effects scale with the number of rows loaded.

For more information, see Using Partial Records.

Table extension impact on performance (for Business Central 2023 release wave 1 and earlier)

Table extensions are separate tables in the database and therefore need to be joined together in the data stack when accessed via a record. With tables extensions being stored individually, the amount of joins necessary grows with the number of table extensions extending a table. Together with the current inability to define indexes that span base and extension fields, one should avoid splitting one's code into too many table extensions.

With central tables to the application, such as General Ledger Entry (G/L Entry), one should be extra cautious adding table extensions since these tables are frequently used throughout the application.

The adverse affects of many table extensions can be mitigated with the application of partial records, see Using Partial Records. However, since the developer may not have ownership of all executed code, and therefore isn't able to apply partial records everywhere, the above recommendation still stands.

An alternative approach when doing data modeling for extending a table with new fields is to use a related table and define a FlowField on the base table.

Here are the pros and cons of the two data models:

Data model for extending a table	Properties
Table extension	Fields can be added to lists and are searchable. Always loaded with the base table. Expensive at runtime but easy to use. Use only for critical fields.
Related tables	Need to set up table relations. Dedicated page for editing. Requires flow field to be shown in lists. Doesn't affect performance of base table. Excellent for FactBoxes.

Limit your event subscriptions

The following are best practices for getting performant events:

• There's no significant cost of having a publisher defined.
• Static automatic has a cost over manually binding (there's an overhead of creating and disposing objects).
• Codeunit size of the subscriber matters. Try to have smaller codeunits.
• Use single instance codeunits for subscribers, if possible.

Table events change the behavior of SQL optimizations on the Business Central Server in the following ways:

• The Business Central Server will issue SQL update/delete statements row in a for loop rather than one SQL statement.
• They impact ModifyAll and DeleteAll methods that normally do bulk SQL operations to be forced to do single row operations.

Outgoing web service calls block AL execution

If you call an external web service using the HttpClient module in AL, be aware that the Business Central Server blocks the execution of AL code for the session until the call completes. For interactive sessions, this behavior means that the user sees a spinning wheel during the call.

If you have enabled telemetry for your environment or app, you can use this KQL query to analyze how much time users are delayed in the UI by calls to external services.

traces
| where customDimensions has 'RT0019'
| where customDimensions.clientType == 'WebClient'
| extend executionTimeInMs = toreal(totimespan(customDimensions.serverExecutionTime))/10000 //the datatype for executionTime is timespan
| summarize count() // how many calls
, sum(executionTimeInMs) // sum of delays for UI sessions
, avg(executionTimeInMs) // average waiting time by this app
, max(executionTimeInMs) // average waiting time by this app
by 
// which app is calling out from the UI
  extensionPublisher = tostring( customDimensions.extensionPublisher )
, extensionName = tostring( customDimensions.extensionName )
, extensionVersion = tostring( customDimensions.extensionVersion )

Limit work done in login event subscribers

The events OnCompanyOpen and OnCompanyOpenCompleted are raised every time a session is created. Only when the code for all event subscribers on these events has completed can the session start running AL code. Until code has completed, the session creation process will wait. For interactive sessions, the user will see a spinner. Web service calls (SOAP, OData, or API) or background sessions (job queue, scheduled tasks, page background tasks) will not start running.This behavior means that you must design such code in a way that is minimally intrusive, for example, set low timeouts for outgoing web service calls.One or more of these operations typically are involved in a performance issue on logins: 1. Calls to external services 2. Long running SQL calls to the databaseIf you have enabled telemetry for your environment or app, you can use this KQL query to analyze how session creation time is delayed by calls to external services.Kusto traces | where timestamp > ago(1d) // adjust as needed | where customDimensions.eventId == 'RT0019' | where isnotempty( customDimensions.alStackTrace ) // RT0019 only has stacktrace from 20.1 | extend StackTrace = tostring( customDimensions.alStackTrace ) , executionTimeInMs = toreal(totimespan(customDimensions.serverExecutionTime))/10000 //the datatype for executionTime is timespan | where StackTrace has 'OnCompanyOpen' or StackTrace has 'OnCompanyOpenCompleted' | summarize count() // how many calls , sum(executionTimeInMs) // sum of delays for session creations (all session types are affected: UI, web service, background, ...) , avg(executionTimeInMs) // average session creation time delay by this app , max(executionTimeInMs) // average session creation time delay by this app by // which app is calling out from OnCompanyOpen/OnCompanyOpenCompleted? extensionId = tostring( customDimensions.extensionId ) , extensionName = tostring( customDimensions.extensionName ) , extensionVersion = tostring( customDimensions.extensionVersion ) // session type: UI, web service, background, ... , clientType = tostring( customDimensions.clientType ) Use this KQL query to analyze how session creation time is delayed by calls to the database:Kusto traces | where timestamp > ago(1d) // adjust as needed | where customDimensions.eventId == 'RT0005' | where isnotempty( customDimensions.alStackTrace ) // RT0019 only has stacktrace from 20.1 | extend StackTrace = tostring( customDimensions.alStackTrace ) , executionTimeInMs = toreal(totimespan(customDimensions.executionTime))/10000 //the datatype for executionTime is timespan | where StackTrace has 'OnCompanyOpen' or StackTrace has 'OnCompanyOpenCompleted' | summarize count() // how many calls , sum(executionTimeInMs) // sum of delays for session creations (all session types are affected: UI, web service, background, ...) , avg(executionTimeInMs) // average session creation time delay by this app , max(executionTimeInMs) // average session creation time delay by this app by // which app is querying the database extensionId = tostring( customDimensions.extensionId ) , extensionName = tostring( customDimensions.extensionName ) , extensionVersion = tostring( customDimensions.extensionVersion ) // session type: UI, web service, background, ... , clientType = tostring( customDimensions.clientType ) )

Efficient data access

Many performance issues are related to how data is defined, accessed, and modified. It's important to know how concepts in AL metadata and the AL language translate to their counterparts in SQL.

Tables and keys

Many performance issues can be traced back to missing indexes (also called keys in Business Central), but index design is often not a key skill for AL developers. For best performance, even with large amounts of data, it's imperative to design appropriate indexes according to the way your code will access data.

These articles on indexing are worth knowing as an AL developer:

• About Table Keys
• Table Keys and Performance in Business Central
• About SQL Server indexes
• Missing Indexes

Indexes have a cost to update, so it's recommended to not add too many of them on a table.

Using data audit fields to only read recent data

Every table in Business Central) includes the following two system fields, which can be used for filtering records:

• SystemCreatedAt
• SystemModifiedAt

One example is to use the system field SystemModifiedAt to implement delta reads. For more information about system fields, see System Fields.

Non-clustered Columnstore Indexes (NCCI)

Starting in the 2021 release wave 2 of Business Central, non-clustered columnstore indexes (sometimes referred to as NCCIs) are supported on tables.

You can use a non-clustered columnstore index to efficiently run real-time operational analytics on the Business Central database without the need to define SIFT indexes up front (and without the locking issues that SIFT indexes sometimes impose on the system.)

Read more about non-clustered columnstore indexes here:

• ColumnStoreIndex table property
• Columnstore indexes overview

SumIndexField Technology (SIFT)

SumIndexField Technology (SIFT) lets you quickly calculate the sums of numeric data type columns in tables, even in tables with thousands of records. The data type includes Decimal, Integer, BigInteger, and Duration. SIFT optimizes the performance of FlowFields and query results in a Business Central application.

Ensure appropriate SIFT indices for all FlowFields of type sum or count.

Read more about SIFT here:

• SumIndexField Technology (SIFT)
• SIFT and Performance
• Tuning and Tracing
• SIFT and SQL Server

The following article can help you find missing SIFT indexes on FlowFields:

Troubleshooting: Long Running SQL Queries Involving FlowFields by Disabling SmartSQL.

How AL relates to SQL

The AL programming language, to some degree, hides how data is read and written to the database. To effectively code for performance, you need to know how AL statements translate to the equivalent SQL statements.

The following articles cover how AL relates to SQL:

• AL Database Methods and Performance on SQL Server
• Data Access
• Data read/write performance
• Bulk Inserts

How to get insights into how AL translates to SQL

If you want to track how Business Central Server translates AL statements to SQL statements, use either database statistics in the AL debugger or telemetry on long running queries.

Read more here:

• About database statistics in the AL debugger
• Telemetry on Long Running SQL Queries

How to reduce database locking

Sometimes, performance issues aren't due to resource starvation, but due to processes waiting for other processes to release locks on shared objects. When AL code needs to update data, it's customary to take a database lock on it to ensure that other processes don't change the data at the same time.

Using the Record.LockTable method, this will apply the WITH (updlock) hint on all subsequent calls to the database until the transaction is committed, not only on the table that the record variable is defined on, but on all calls to the database. Hence, it's good practice to defer the Record.LockTable call as late as possible in your AL code, to make sure that only the data that is in scope for being updated, is locked. Read more here: Record.LockTable Method

Some tips for avoiding locking:

• Read setup information before starting write transactions
• If possible, limit the time you hold locks
• If possible, limit transaction size (divide into smaller operations that can be committed)
• Make sure you have indexes on ranges you update
• Locking is much less of an issue if you have a logical separation across companies
• Set record instance isolation level on transactions to isolate them from other transactions to prevent problems in concurrent situations. Learn more about record instance isolation level.

Database locking caused by web service calls

Don't insert child records belonging to the same parent record in parallel. This condition causes locks on both the parent table and the integration record table because parallel calls try to update the same parent record. The solution is to wait for the first call to finish or use OData $batch, which will make sure calls get run one after another.

Non-blocking number sequences

If you need a fast, non-blocking number sequence that can be used from AL, refer to the number sequence object type. Use a number sequence object if you:

• Don't want to use a number series
• Can accept holes in the number range

For more information, see NumberSequence Data Type.

Analyzing database locks

There are two tools that you can use to analyze database locks happening in the environment: the Database Locks page, and database lock timeout telemetry.

The Database Locks page gives a snapshot of all current database locks in SQL Server. It provides information like the table and database resource affected by the lock, and sometimes also the AL object or method that ran the transaction that caused the lock. These details can help you better understand the locking condition.

Database lock timeout telemetry gathers information about database locks that have timed out. The telemetry data allows you to troubleshoot what caused these locks.

Read more here:

• Viewing Database Locks
• Monitoring SQL Database Locks
• Analyzing Database Lock Timeout Trace Telemetry

Using Read-Scale Out

Business Central supports the Read Scale-Out feature in Azure SQL Database and SQL Server. Read Scale-Out is used to load-balance analytical workloads in the database that only read data. Read Scale-Out is built in as part of Business Central online, but it can also be enabled for on-premises.

Read Scale-Out applies to queries, reports, or API pages. With these objects, instead of sharing the primary, they can be set up to run against a read-only replica. This setup essentially isolates them from the main read-write workload so that they won't affect the performance of business processes.

As a developer, you control Read Scale-Out on report, API page, and query objects by using the DataAccessIntent property. For more information, see Using Read Scale-Out for Better Performance.

Testing and validating performance

It's imperative to test and validate a Business Central project before deploying it to production. In this section, you find resources on how to analyze and troubleshoot performance issues and guidance on how to validate performance of a system.

Performance Unit Testing

You can use the SessionInformation data type in unit tests that track the number of SQL statements or rows read. Use it before and after the code to be tested. Then, have assert statements that check for normal behavior.

For more information, see SessionInformation Data Type.

Performance Scenario and Regression Testing

Use the Performance Toolkit to simulate the amount of resources that customers use in realistic scenarios to compare performance between builds of their solutions.

The Performance Toolkit helps answer questions such as, "Does my solution for Business Central support X number of users doing this, that, and the other thing at the same time?"

For more information, see The Performance Toolkit Extension.

Performance Throughput Analysis

The Performance Toolkit doesn't answer questions such as, "How many orders can Business Central process per hour?" For this kind of analysis, test the time to execute key scenarios using the Performance Toolkit, and then use the guidance on Operational Limits for Business Central Online. For advanced analysis, consider using a queueing model such as a M/M/1 queue to answer whether the system can process the workload you intend.

Performance telemetry

The following performance telemetry is available in Azure Application Insights (if that has been configured for the environment):

• Database locks
• Long Running AL operations
• Long Running SQL Queries
• Page views
• Reports
• Sessions started
• Web Service Requests

For more information, see the Analyzing performance issues using telemetry section.

Troubleshooting

The following articles can be of help in troubleshooting performance issues:

• Find missing SIFT indexes for FlowFields by Disabling SmartSQL
• Use Page Inspection to find extensions participating on a page
• Viewing Table Sizes

Tuning the Development Environment

The following articles explain what you can do as a developer to tune your development environment for better performance:

• Optimizing Visual Studio Code for AL Development
• Code Analysis on large projects

See Also

Performance Overview
How Application Configurations Affect Performance
Performance Online
Performance of On-Premises Installations
How to Work with a Performance Problem
Performance tips for business users
Database Missing Indexes
AL Database Methods and Performance on SQL Server