Response time on forms A response time indicator (clock) appears at the bottom right of many forms and lists. This indicator provides the processing time for a completed transaction, including the total time and the time for each step. Click the icon to show and hide the response time details. Point to the icon to see a tooltip with the details. The following example shows the response time for retrieving a filtered list in a demo instance. Figure 1. Response time In this example, the transaction took the following amount of processing time: 1019 milliseconds total time 3 milliseconds moving data across the network 526 milliseconds on the server 490 milliseconds in the browser, rendering the HTML and parsing and executing JavaScript Response does not appear for simple operations, such as paging, changing a list sort order, or for the first transaction in a session. To view a detailed breakdown of the browser processing time on forms, click browser. Figure 2. Browser response time details Administrators can disable the response time by setting the glide.ui.response_time property to false. When you review response times, look for the following issues. A period where all transactions took an unusually long time. For example, transactions that normally took 1 second took 15 seconds between 11:00 AM and 11:20 AM. This issue can indicate that an unusual load, such as a large report, ran on that app server during that time. A specific transaction which repeatedly took an unusually long time. For example, the list of closed incidents sorted by short description took 30 seconds each time it was displayed. This issue can indicate that a particular transaction put an unusual database load on the system, such as sorting 500,000 records on an unindexed field. Try the following actions to improve performance. Look for one or more transactions that span the entire window. For example, you observe that the response was slow for six minutes and one transaction ran the entire time. You can try adding additional indexing to the database to make the transaction faster. Certain types of queries are always going to run more slowly than others, regardless of indexing. Ensure that a cache flush is not being run during business hours. Cache flushes are intended to prevent older data from interfering with changes and updates, and are performed automatically when using update sets. Scheduled cache flushes, using cache.do, can affect overall performance, and degrade system response times. Do not run cache flushes during business hours, and do not trigger cache flushes automatically. If you cannot find any specific issues when experiencing slow response time, contact support to see if there are global issues with the application server hardware. Client transaction timings The Client Transaction Timings plugin provides extra information about the amount of time spent on both the client and server side, and by the browser and network. This feature not only helps find long-running processes, but also provides information about where in the process the performance issue is caused.
Response time on forms A response time indicator (clock) appears at the bottom right of many forms and lists. This indicator provides the processing time for a completed transaction, including the total time and the time for each step. Click the icon to show and hide the response time details. Point to the icon to see a tooltip with the details. The following example shows the response time for retrieving a filtered list in a demo instance. Figure 1. Response time In this example, the transaction took the following amount of processing time: 1019 milliseconds total time 3 milliseconds moving data across the network 526 milliseconds on the server 490 milliseconds in the browser, rendering the HTML and parsing and executing JavaScript Response does not appear for simple operations, such as paging, changing a list sort order, or for the first transaction in a session. To view a detailed breakdown of the browser processing time on forms, click browser. Figure 2. Browser response time details Administrators can disable the response time by setting the glide.ui.response_time property to false. When you review response times, look for the following issues. A period where all transactions took an unusually long time. For example, transactions that normally took 1 second took 15 seconds between 11:00 AM and 11:20 AM. This issue can indicate that an unusual load, such as a large report, ran on that app server during that time. A specific transaction which repeatedly took an unusually long time. For example, the list of closed incidents sorted by short description took 30 seconds each time it was displayed. This issue can indicate that a particular transaction put an unusual database load on the system, such as sorting 500,000 records on an unindexed field. Try the following actions to improve performance. Look for one or more transactions that span the entire window. For example, you observe that the response was slow for six minutes and one transaction ran the entire time. You can try adding additional indexing to the database to make the transaction faster. Certain types of queries are always going to run more slowly than others, regardless of indexing. Ensure that a cache flush is not being run during business hours. Cache flushes are intended to prevent older data from interfering with changes and updates, and are performed automatically when using update sets. Scheduled cache flushes, using cache.do, can affect overall performance, and degrade system response times. Do not run cache flushes during business hours, and do not trigger cache flushes automatically. If you cannot find any specific issues when experiencing slow response time, contact support to see if there are global issues with the application server hardware. Client transaction timings The Client Transaction Timings plugin provides extra information about the amount of time spent on both the client and server side, and by the browser and network. This feature not only helps find long-running processes, but also provides information about where in the process the performance issue is caused.
