Analyze performance issues on Service PortalSummaryCertain pages on Service Portal load very slowly, either when navigating to them or accessing them directly. This is commonly because one or a few widgets are taking most of the time to load. This article describes how to identify these scenarios.ReleaseApplicable to all releasesInstructions1. Determine which page is loading slowly. You can find this by following the Steps to Reproduce the issue, otherwise, load the page and look for the value present in the URL for id param (for example /sp?id=list) 2. Once identified, find out how much time it is taking for the page to load. You can check this on the browser dev tool's Network tab. This will tell how much time is taken on what aspect. In the following screenshot from a use case, notice the total time taken is 5.43 seconds, which is mostly waiting time of around 4 seconds. If the waiting time is taking the most of the time, this means that the response from the server takes longer. 3. Once it is determined that server time is taking more time, see which server functionality is responsible. There could three scenarios: Slow running ACLSlow running business rulesSlow running SQL queries. 4. To find out which of these are consuming the most time, go to System Diagnostics > Session Debug > Debug Log. 5. After enabling the debug log, reproduce the issue and try to get the logs on the jsdebugger window or on a ui_page.do. If this transaction has taken more time, a log similar to the following will appear. The key word is EXCESSIVE. log05:15:20 AM.771 EXCESSIVE *** End #2298398 /api/now/sp/page, user: admin, total time: 0:00:06.484, processing time: 0:00:06.484, SQL time: 0:00:05.209 (count: 887), business rule: 0:00:00.001 (count: 6), ACL time: 0:00:00.001, Cache build time: 0:00:00.007, source: 103.23.66.61 , type:rest, method:GET, api_name:now/sp, resource:now/sp/page, version:Default, user_id:admin, response_status:200 This log shows which component has taken the most time. For this use case, the total time was around 6 seconds. This was distributed as SQL time= 5s, Business Rule= 1ms and ACL= 1 ms. This means that SQL queries are taking the most time. 6. Once the component is known, look for that transaction's specific function. Remember to note the request URL that initiated this transaction. In this use case, it is an API call, /api/now/sp/page, which can be seen in the network logs. 7. Enable the session debug of that component. In this case, enable Debug SQL (detailed). Enabling the detailed log shows the trace of the queries and provides the sys_id of the widget that caused the slowdown. 8. As the SQL debug is enabled, reproduce the issue, and then reload the ui_page.do to get the new logs. 9. Search with the API name and look for the transaction name under Queries, as shown in the following screenshot. This gives an explanation of how much time is taken by all the queries, per-transaction basis, and which query took what percentage of the time. 10. Once the query taking the most time is discovered (the product default view shows the long-running one at the top), search for the query in the logs, as shown in the following image. Copy the end part of the query to search, as the selection fields are usually hidden in the SQL statements. This returns the exact SQL entry logs, and the SQL log can be expanded to see which widget is causing the delays. 11. Analyze the widget, and then modify the query based on that analysis. This example shows the slowness is caused on Query. If it was caused by either Business Rule Or ACL, enable the respective session debug. This identifies which transactions takes the most time. Those can then be investigated and solved accordingly. Related LinksScript Debugger and Session LogSession Debug