ServiceNow Servlet

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

If you have the admin role, you can review performance metrics. To view servlet graphs on the ServiceNow Performance homepage:

1. In the Graph Set list, select ServiceNow Servlet.
2. In the Monitorable Items list, select an instance.
3. In the Timespan list, select a time period.

For details on using the graph and display controls on the ServiceNow Performance homepage, see Platform performance metrics.

Figure 1. ServiceNow Servlet graphs

• 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: The thread is 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: The thread is writing data out to the network or waiting for an outbound network buffer to flush.
  • Concurrency: The threads 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 the instance receives a transaction and the time the instance responds. Displays the time 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 a CPU.

• Sessions: Shows active sessions, including those sessions initiated by the MID Server and external integrations. Large numbers 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 Entry [syslog_transaction] and view the Session wait time to find the transactions that are waiting. Next, find the 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 run in parallel.

  Long-running transactions on a semaphore can back up all semaphores, causing transactions to wait. The platform manages semaphores, requiring no customer administration. The semaphore graph is used only by Customer Service and 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 Customer Service and Support.

• Scheduler Queue Length/ Scheduler Completed Jobs: 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.
• Errors: Shows any severe errors printed to the localhost logs or syslog_transactions. Multiple severe errors indicate a problem that requires further investigation.
• Events Processed: Shows the average number of events processed during the selected time period.
• Events Logged: Shows the average number of 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.
• Semaphore Rejections: Display the number of transactions rejected by the following semaphore queues:
  • Semaphore Default Rejected Execution
  • Semaphore Debug Rejected Execution
  • Semaphore AMB Receive Rejected Execution
  • Semaphore AMB Send Rejected Execution
  • Semaphore API INT Rejected Execution
  • Semaphore Presence Rejected Execution
  Identify processing bottlenecks by monitoring rejection counts in the queues. Look for spikes in the semaphore rejection graphs. A high rejection count indicates an unexpected proliferation in calls. Reduce the number of calls or stop long-running transactions that might be backing up the queue.