Power Apps — Troubleshooting Performance Issues — Part 2
In this article, we continue our exploration of other areas that might impact Power Apps performance issues. In particular, we look at API throttling and caching issues.
API throttling
Slowness/throttling/429 errors are the most common side effects when Dataverse API usage exceeds the service protection limits.
What are the error messages when Dataverse OData/SDK requests are throttled?
- 429 Too Many Requests
- Number of requests exceeded the limit of 6000 over time window of 300 seconds.
- Combined execution time of incoming requests exceeded limit of 1,200,000 milliseconds over time window of 300 seconds.
- Number of concurrent requests exceeded the limit of 52.
Why are throttling limits enforced?
To ensure consistent availability and performance, Microsoft applies some limits to how APIs are used. These limits are designed to detect when client applications are making extraordinary demands on server resources.
How throttling limits are enforced?
Throttling limits are enforced based on three facets for both OData and SDK requests.
- The number of requests sent by a user.
- The combined execution time required to process requests sent by a user.
- The number of concurrent requests sent by a user.
How to resolve throttling errors?
- Try to distribute the requests more evenly over time, instead of sending a large burst over a short period.
- Try to distribute requests evenly across multiple web servers (e.g., by setting use cookies = false)
- If number of requests are exceeding the limit, you may send small batch requests.
- Too many slow requests may cause time usage/concurrency throttling. Identify slow request and optimize.
- Follow the best practices — Honor retry-after, avoid large batches etc.
- Increasing licenses can automatically increase the capacity.
There are a few strategies to improve slowness related to API Throttling.
Cache Issues
Caching issue on the client side
When loading the top landing page and dashboard pages, which often consist of multiple panes, the browser must concurrently load numerous script and style files. Once these files are cached on the client side, loading speed improves. However, during the initial load (when files are not yet cached), it is intentionally slower.
If you capture a network trace file with the “Disable Client Cache” option, you will consistently encounter this issue. If you are addressing initial loading issues for a rich dashboard page or the top landing page, take this into account.
Additionally, if you observe many “Stalled” requests that take a long time, check the concurrent requests limit.
While a brief period of stalling during initial loading is expected, it should not result in visible slowness for the client.
Caching issue at the server side
When you encounter multiple GetClientMetadata calls that take longer than usual, you may be the first user to connect through a specific web server for Dynamics 365.
In this scenario, the web server needs to load metadata (such as a list of tables and columns) from the database and cache it in memory for your environment.
While this cost is typically negligible when many users are sharing the same environment, it becomes more noticeable if you’re the sole user of your development environment or when someone publishes customizations.
This phenomenon, often referred to as cold load, may occur more frequently in such cases.
A cold cache load is the process of loading data into a cache that is empty or has stale data. This means that the data is not readily available and has to be retrieved from a slower source.
If slowness is due to first-time requests every day, it is explained by product design. The first-time requests might be slow due to a cold cache load. Subsequent requests will be faster.
Caching is a good technique to improve the performance of applications by storing data that is expensive to retrieve or infrequently changing in memory or other storage devices.
Please check the below for the series link
