ServiceNow servlet performance metrics

SAVE AS PDF

ServiceNow
servlet
performance metrics

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

To view servlet graphs
on
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
on
the
Performance
homepage, see Performance metrics.

Figure 1. 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
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
Entry [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
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 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
(memory management) can occur, which can degrade performance. This graph can
help identify low memory situations due to objects
not
picked up during garbage collection.

Garbage Collection Activity: Shows the percent of time
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
service
performance
degradation.

Logs: Shows the average number of logs created for the instance
during the given timespan.

Errors:
Shows
any severe errors
printed
to the localhost logs or
syslog.
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.