Instance View

Review data points across all near nodes (instances) using the Instance View graph set. In a single view, you can review how all active nodes are responding and identify which nodes are experiencing issues.

If you have the admin role, you can review performance metrics. Follow this procedure to view instance performance graphs on the ServiceNow Performance homepage:

1. In the Graph Set list, select Instance View.
   • The Monitorable Items list and Compare With selections are both disabled.
   • The Monitorable Items list has a value -All- for all near (active primary) instances, and excludes far (primary offline or active secondary) instances.
   • Each metric displays data across all active nodes. For example, if you have three instances, all three appear in each metric.
     Note:

     You can view performance metrics for up to 49 near nodes. If you have more than 49 nodes, no data appears for the 50th instance and above.
2. In the Timespan list, select a time period.
3. To overlay diagnostic events that have taken place during the time span you requested, toggle Show on graphs, which appear next to Diagnostic Events.

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

Figure 1. Instance View

• 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.
• 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.

Isolating data for specific instances

Using the Fullscreen View, you can isolate information for specific instances in a selected metric.

1. Select a metric, and then click the Fullscreen icon to open an enlarged view of the graph.

   

2. Clear the check box next to the instances you want to exclude.
   • For example, clear the check box next to Instance_8080 to exclude its data.
   • Only data for Instance_8081 and Instance_8082 appears.