Transaction or response metrics
Summarize
Summary of Transaction or response metrics
This information explains key performance metrics for classic UI transactions within the ServiceNow AI Platform®. These metrics help you understand transaction volumes, server response times, and the distribution of response time components such as server, network, and browser times. They provide insights into core business hours performance and help identify potential performance issues.
Show less
Key Metrics Explained
- User Transaction Count (sum): Represents the total number of classic UI transactions (UITYPE) across the instance, excluding AJAX, Angular, REST, Scheduler, Agent Workspace, and other modern transaction types. It primarily covers whole-page table-based form/list transactions. This metric is useful to gauge transaction volume during core business hours and to detect significant changes that might signal performance issues. However, it should be used only as a secondary indicator and not for direct troubleshooting.
- Average Server Response Time (weighted average): Measures the average execution time of UITYPE transactions on the server side, excluding semaphore wait times, session sync wait times, network latency, and client-side processing. Server response times typically fluctuate with business hours and transaction types, and longer response times during off-hours may be influenced by administrative activities. This metric should be interpreted cautiously, focusing on extreme deviations or correlation with other indicators rather than fixed thresholds.
- Stacked Time Components: Provides a breakdown of total transaction response time into three parts:
- Server Time: Time spent by the server processing the transaction, excluding redirects, AJAX calls, resource serving, and wait times for semaphores or previous session transactions. This metric can be inflated if significant waiting occurs.
- Network Time: Time taken by the server to write the request bytes to the output stream, not the actual network transmission time. This is typically much lower than expected.
- Browser Time: Time spent by the browser rendering the request and response, usually less than server time but important to identify client-side performance bottlenecks.
Practical Guidance for Customers
- High server response time suggests reviewing server-side components such as business rules, ACLs, SQL queries, semaphore waits, and session waits.
- High network time indicates the need to assess transaction data volume and optimize data streaming.
- High browser time points to reviewing client-side scripts and components for performance improvements.
- Use these metrics as part of a holistic approach; they provide a partial view of end-user performance and should be supplemented with other system performance measurements.
The metrics provide a performance snapshot of classic UI transactions within the ServiceNow AI Platform®.
User transaction count (sum)
Transaction count is the instance-wide sum of all UI transactions of a certain type known as UI_TYPE, which is a classification used only in ServiceNow proprietary code.
UI_TYPE excludes all AJAX, Angular, REST (including all ServicePortal and /api/now/ui/), Scheduler, Agent Workspace, SOAP etc. Essentially, it can be considered to cover only classic, whole page transaction types for example, table based form/list transactions excluding List V3, home pages, UI pages.
This is useful to understand core business hours. Potentially useful as a secondary identifier of extreme performance issues if the number rapidly changes in minutes and stays that way for at least 10 minutes either up or down.
Average server response time (weighted average)
Server response time in this context is the average/mean execution time for UI_TYPE transactions. See Transaction Count (sum) for limitations of this classification.
- Time spent on waiting for a semaphore (if all semaphores are used by other users).
- Time spent waiting for session sync (if current user already has an active transaction).
- Time spent on the network back and forth to ServiceNow.
- Time spent on the client-side by the browser or mobile device.
Server response time commonly fluctuates up and down in relation to core business hours due to the type of operations that tend to occur at any given time. Thus, it is very common that server response time appears more volatile during nights and weekends because administrators are running long reports or administrative transactions that typically take longer to execute. This, combined with the fact that fewer overall transactions are occurring, means a few slow transactions will have greater impact on the average.
When considering long-term trends, like Week over week comparisons for example, one should consider that such changes may simply reflect usage pattern changes, such as users doing more or less of certain types of transactions that are typically faster or slower. Because each transaction type has different functional requirements, there is no arbitrary threshold for what constitutes a slow transaction and thus no threshold should be applied to this metric. Instead of looking at long-term trends or short spikes outside core business hours, attention should be placed on extreme deviations from the norm or where this metric coincides with another performance indicator.
Since this metric is limited to the response time of UI_TYPE transactions (see definition under Transaction Count (sum)), it may be a very incomplete picture of your end user's performance. Other methods of measuring should be considered for aspects of total system performance.
Stacked time: Server response time, Network time (network time, both from and to the user) and browser time
Server, network, and browser response times are three key metrics in the life cycle of a transaction. Average Stacked time of a transaction provides an response time from three metrics in a pile of objects.
- Server Time
- The number of milliseconds spent by the server in fulfilling the transaction. It does not include:
- server time spent prior to a redirect (HTTP 302)
- time spent on subsequent, partial page requests (that is, AJAX) or serving up a resource (CSS, JavaScript, images, etc)
- wait time from waiting for a semaphore or waiting for a previous transaction on the same session to complete
Therefore, this can be a confusing and inflated metric because some transactions may have 90% or more of their response time spent waiting for another transaction to complete.
- Network Time
- It is the time it takes the server to write all the bytes of the request to the output stream - not the time it takes to transmit those bytes across the internet. This is not what most people expect from this measurement. It is much lower than what most people would expect.
- Browser Time
- It is the time taken by the browser during the transaction. It includes the request and response rendering time at the browser.
It gives a perspective of what is the biggest contributor for the total response time for a transaction. Usually, Server time is high compared to Network and Browser.
- The server response time is high, then server side components must be reviewed further like business rule, ACL, SQL, Semaphore wait, Session wait time, and others.
- The network time is high, then transaction components and how much data is being streamed must be reviewed. Recommendation is to keep lightweight transactions with optimal data stream.
- The browser time is high, then client side scripts/components must be reviewed.