ServiceNow servlet performance metrics

Each instance has a servlet, and you can monitor its performance using the servlet graph set in the Performance homepage.

To view servlet graphs in the Performance homepage, select ServiceNow Servlet in the Graph Set list, an instance in the Monitorable Items list, and a time period in the Timespan list.

For details on using the graph and display controls in the Performance homepage, see Performance metrics.

Figure 1. Servlet graphs
Servlet performance metrics
  • System Overview: Provides thread performance information. Every second, the system looks at all active threads (both UI and background) and places them into one of the following categories.
    • CPU: The thread is active, but is not executing any of the steps. This condition typically means non-business rule compute time, although in this case a few other internal wait states are categorized as CPU. Therefore a 1:1 correlation between threads in a CPU count and hardware CPU utilization is not expected.
    • Database: Waiting for information from the database.
    • Business Rule: The system is running a business rule (synchronous or asynchronous) and is not currently executing a query (which would be database).
    • Network: Writing data out to the network or waiting for an outbound network buffer to flush.
    • Concurrency: Cannot run because they are waiting on a semaphore or session synchronization.

    The system averages these transactions every minute and records them in the database. The graph shows the averages for each category.

  • Transactions: Displays all UI transactions initiated by users. This graph can show large spikes in end-user traffic and identify when peak end-user activity occurs.
  • Response Time: Displays the interval (in milliseconds) between the time that the instance receives a transaction and the time the instance responds. Displays the time that the server takes to complete a transaction on average, during the given time span. An increase in average response time might indicate that there is a systemic issue or an influx of generally slower transactions. To identify possible performance problems, you can correlate response time with other areas, such as memory, database, or CPU.
  • Sessions: Shows active sessions, including those sessions initiated by the MID Server and external integrations. A large number of stale but active sessions can lead to memory and performance issues. Session counts larger than 10,000 can typically result in performance degradation. Consider reviewing integration session guidelines and limiting session timeouts.
  • Session Wait Queue: Displays the number of transactions that are waiting on another transaction for the same user. Waiting sessions occur when a user submits a duplicate request before the prior request completes. Can indicate a slow page or a transaction that requires further investigation. To identify the transactions that are waiting, check the Transaction Log [syslog_transaction] and view the Session wait time to find the transactions that are waiting. Next, find the transaction [Transaction Number?] that the user is waiting on.
  • Semaphore Use: Shows the number of semaphores in use by the selected instance. Semaphores control the number of user transactions that can be run in parallel. Long-running transactions on a semaphore can back up all semaphores, causing transactions to wait. The platform manages semaphores, and they require no customer administration. The semaphore graph is used only by ServiceNow Customer Support for troubleshooting.
  • Semaphore Wait Queue: Shows the wait queue for a semaphore. Use this graph with the Semaphore Use graph. A high wait queue indicates long-running transactions on the semaphore. A high and persistent semaphore queue can indicate that the instance node is overloaded with work. Check the Transaction Log [syslog_transaction] to find the longest-running transactions during that time period and identify the problem. This graph is used only by ServiceNow Customer Support
  • Scheduler: Displays all scheduler activity for the selected instance, including Discovery probes. You can determine the backlog of scheduled jobs in the queue for a particular time period. You can then compare that against the rate at which the jobs are being processed during the same period.
  • Java Memory: Records memory usage and indicates when the instance is running out of memory. The Java Memory graph is a useful problem indicator.
  • Java Garbage Collection Floor: Shows the minimum memory floor and the memory currently consumed. Use this graph to identify high memory consumption. The higher the minimum memory floor, the less memory is available for processing on the server. When less memory is available, excessive garbage collection can occur, which can degrade performance. This graph can help identify low memory situations due to objects that are not picked up during garbage collection.
  • Garbage Collection Activity: Shows the percent of time that the server performs garbage collection. When the Java Virtual Machine (JVM) collects garbage, all processing stops until garbage collection is completed. High garbage collection times over a few percent can lead to a degradation in server performance.
  • Metaspace: Shows the native memory used for storing the class metadata in JDK 8. Metaspace replaces PermGen space in JDK 8.
  • Logs: Shows the average number of logs created for the instance during the given timespan.
  • Errors: This graph shows any severe errors that were printed to the localhost logs or syslog. Multiple severe errors indicate a problem that requires further investigation.
  • Events Processed: Shows the average number of the events processed during the selected time period.
  • Events Logged: Shows the average number of the events queued and added to the event log in the selected time period.
  • HTTP Transactions: Displays all completed HTTP transactions, including UI, integration, and AMB traffic. This graph can show large spikes in HTTP traffic and can help identify when peak user activity occurs.