HELSINKI METROPOLIA UNIVERSITY OF APPLIED SCIENCES

Network Management Systems, Demo 7

Performance Monitoring

Performance

Applications can be divided into the following three categories, depending on

performance requirements and experiences of the end user:

In a transaction oriented application a user initiates a transaction and waits until

it is completed. Retrieving a web page lies in this application. In this case, user
experience depends on the wait time: the lower the user waits, the better the
service.

Performance of a throughput-oriented application depends on available

bandwidth, for example when downloading a large file. The higher the
bandwidth, the lower the download time, and the better the service.

Usage of a streaming application either succeeds or fails depending on

transmission quality. If the packet drop rate, delay or delay variation for an IP
Telephony call is too high, the voice quality is not sufficient.

PRTG

Often the Service Provider does performance monitoring, to verify compatibility with
the Service Level Agreement. Often large complex (and expensive) systems are used for
monitoring performance. There is very few open source performance monitoring
software available. Some aspects of performance monitoring, like response time
monitoring, are included in open source network management and monitoring software.

PRTG, by Paessler, is a commercial closed source network monitoring software,

targeted mostly for small and medium sized networks. PRTG monitors network and
network component availability and network and system parameters (like CPU
utilization and bandwidth usage). It also includes some small-scale tools for
performance monitoring. A free-to-use version with limited sensor capacity is available,
together with a time-limited evaluation version. Prizes for the commercial versions start
from 250 .

PRTG Core Server runs on a Microsoft Windows host. It may discover network
components automatically, and it stores device data and monitoring results on a vendor-
specific database. Data is accessible from any workstation (even from Apple iPhone)

VANHA MAANTIE 6 NETWORK MANAGEMENT SYSTEMS 1

02650 ESPOO
matti.puska@metropolia.fi DEMO 7: PERFORMANCE MONITORING MATTI PUSKA
 HELSINKI METROPOLIA UNIVERSITY OF APPLIED SCIENCES

using a web browser. The Core Server gets the actual monitoring data from a PRTG
probe and from SNMP, WMI, SQL, VMware and NetFlow sensors. Also the PRTG
probe runs on MS Windows, and the Core Server always includes a probe. The system
can send notifications for unusual events using an audible alarm, E-mail, SMS or with a
script, and it keeps logs of active and historical events.

Response Time Monitoring

Response time, i.e. the time from the mouse click until receiving the requested data, is a
good performance indicator for transaction-oriented applications. For end-user
perspective, the sensor must be placed as near the user terminal as possible, and the
target must be the server in question. In reality, it is not possible to monitor response
times from all workstations to all servers and all services. Instead, a set of sensors
should be placed near the end-user workstations (for example in Headquarter and most
important Remote Offices), and the most important server(s) and services are used as
targets. A threshold should be set for the response time, and, when exceeded, a warning
is risen.

Figure 1: Loading time for a web page from the remote Apache server.

VANHA MAANTIE 6 NETWORK MANAGEMENT SYSTEMS 2

02650 ESPOO
matti.puska@metropolia.fi DEMO 7: PERFORMANCE MONITORING MATTI PUSKA
 HELSINKI METROPOLIA UNIVERSITY OF APPLIED SCIENCES

PRTG is installed on a Windows XP virtual host, and it starts up automatically. After

selecting the source and target locations, the PTG setup is simple. Using the Web
interface, I created a suitable group, device and sensor for monitoring HTTP (Devices >
Group View). When opening the Apache_on_aironet_vmnet8 sensor, we see overview,
status and channel information, together with live and history graphs. As shown in
Figure 1, the Live Graph displays the graph for the Loading time, together with data
values.

The target URL was selected when the sensor was created. We can see (and alter) the
HTTP details from the Settings tab. Scanning interval, schedules and access rights are
inherited from the parent device.

Warning thresholds for this sensor are defined as Channels. In the Channels tab, we
define the Upper Error Limit for the loading time, together with graph details. If it takes
more than 200 ms to load the page, an error is generated (Figure 2).

Figure 2: Error threshold for the Loading time, defined as a channel for the sensor.

VANHA MAANTIE 6 NETWORK MANAGEMENT SYSTEMS 3

02650 ESPOO
matti.puska@metropolia.fi DEMO 7: PERFORMANCE MONITORING MATTI PUSKA
 HELSINKI METROPOLIA UNIVERSITY OF APPLIED SCIENCES

The incident is written in the log. We can list all incidents for a given sensor group from
Logs > By Group > Local probe > Real-World_network. Every time when the 200 ms
loading time is exceeded, the sensor is marked Down. Of course, when the normal
loading time is re-reached, this time is also written in the log.

Monitoring Delay, Delay Variation and Packet Drop Rate

For streaming-oriented applications, packet delay (together with packet drop rate)
defines if the service level (like voice quality) is acceptable. PRTG offers the VoIP
sensor, which sends simulated VoIP packets between two PRTG probes. The VoIP
sensor then monitors average jitter, delta time and packet drop rate. The sending and the
receiving probes must be located as near the IP telephony terminals as possible. Using
VoIP sensors need two PRTG probes, and it cannot monitor packet delay (in absense of
common clock).

Another alternative is to monitor two-way Round-Trip Time delay with ICMP ping
packets. The Echo Request and Echo Reply should look like VoIP packets by length,
and intermediate network devices should treat them with the same priority as VoIP
packets. I have set up ping test between two IP hosts (Sensors > By Group > Local
probe > Internet, then select RTT_to_193.166.3.7). As shown in Figure 3, the average
RTT is well below 300 ms (150 ms one-way), but it includes some short high-delay
periods (4 000 ms delay makes interactive voice conversation impossible).

Figure 3: RTT from local probe to 193.166.3.7 with simulated VoIP traffic.

For streaming-oriented applications, performance can be measured as the percent of

time when the network delivers the necessary service level. We have set a 400 ms upper
threshold for the RTT (Channels > Average). When the delay is higher than this, PRTG
marks the probe as down. The performance = portion of the time when the service is

VANHA MAANTIE 6 NETWORK MANAGEMENT SYSTEMS 4

02650 ESPOO
matti.puska@metropolia.fi DEMO 7: PERFORMANCE MONITORING MATTI PUSKA
 HELSINKI METROPOLIA UNIVERSITY OF APPLIED SCIENCES

degraded, can be seen as the average of the downtime (2%), at the lower end of Figure
3.

To get an immediate alarm of degraded voice quality, we set up the system to send an
E-mail notification, when the one-way delay exceeds 200 ms. As we discovered, the
high-delay periods are normally short. As shown in Figure 4, PRTG resends the
notification every 2 minutes, if the delay continues to exceed the threshold. This is
configured in the Notifications tab of the sensor.

Figure 4: Sending a notification with E-mail, when the RTT exceeds 400 ms.

Throughput Monitoring

The actual network throughput in bit/s is a good performance indicator for a throughput-
oriented application, like downloading large files. We pay for the access rate of our
Internet connection, and expect to get almost that throughput, at least from national
sites.

PRTG doesnt directly offer a sensor for throughput measurements. One such
application is Iperf. An Iperf client connects to an Iperf server, and they determine the
TCP or UDP throughput (with given parameters) for the network connection between
them. As shown in Figure 5, the TCP throughput with the default parameters between
the virtual MS Win XP workstation and the host computer is around 100 Mbit/s. We
should start the Iperf as a server in the target computer prior to tests, and allow
incoming Iperf connections:
mattip-air:~mattip$ /Users/mattip/Downloads/iperf-1.7.0-powerpc-apple-
darwin6.4/iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 256 KByte (default)
------------------------------------------------------------

VANHA MAANTIE 6 NETWORK MANAGEMENT SYSTEMS 5

02650 ESPOO
matti.puska@metropolia.fi DEMO 7: PERFORMANCE MONITORING MATTI PUSKA
 HELSINKI METROPOLIA UNIVERSITY OF APPLIED SCIENCES

Figure 5: Throughput test with Iperf.

VANHA MAANTIE 6 NETWORK MANAGEMENT SYSTEMS 6

02650 ESPOO
matti.puska@metropolia.fi DEMO 7: PERFORMANCE MONITORING MATTI PUSKA