Types : Monitors

Types of Monitoring

Basically, there are two approaches to monitor machines under test:

1. Internal Probes/Agents that run within the server (as a process/daemon) and sends counter values to an application like the Windows Task Manager or out to a Diagnostics Mediator/Server
2. External Monitors (such as the unix rstad daemon) that respond to operator commands sent using SSH (Secure Shell) protocol through the network to the server being monitored, which then responds with another transmission over the network.

External Monitors

The amount of resources used by each server in an J2EE or .NET application can be monitored externally by sending requests to Windows performance monitor or commands as a Unix Secure Shell (SSH) session user.

Since all monitoring requests orginate from outside the server being monitored, some call this a "black box" approach to testing.

This is the approach used by Mercury SiteScope, LoadRunner and Business Process Monitor.

Just because a monitor is "agent-less" doesn't mean that it is "non-intrusive" in that it imposes overhead on the system being tested.

Probes/Agents Within Servers

This approach is classified as "white box" testing because probes are installed inside each app server under test (SUT).

This is why product ReliAgent, calls its probes embedded "narks".

After a probe is "instrumented" to recognize methods running on its app server, it makes an announcement whenever it detects invocations of servlets, JSPs, EJBs, JNDI, JDBC, JMS, and Struts.

Probes report on JVM memory heap usage and the memory consumption of Java collections.

MS Windows Task Manager There are several ways to invoke the Task Manager: Press Ctrl-Shift-Esc keys at the same time. Press Ctrl-Alt-Del, then select Task Manager. Press and R at the same time or press then R for Run and press Enter, then type taskmgr and click OK. This sample screen shows both green User mode and red kernel mode CPU Usage because View, Show Kernel Times has been selected: By default, the update speed is set to “Normal”, which means once per second. I prefer the "Low" setting when I see what is hogging up CPU cycles (by clicking the "CPU" heading): Metrics shown in the Processes tab can be selected from View, Select Columns: The above are defaults. Session ID and User Name are new since Windows XP.

Unix Systems Monitoring This section discusses performance monitoring tools among variants of the UNIX operating system which consists of: The kernel, the shell, and the file system. Nagios is a popular open-source performance monitoring. Pro Nagios 2.0 (Apress, 2006, 424 pages) by James Turnbull Site Scope Mercury Site Scope monitors almost all (50) aspects of running Windows and UNIX systems (networks, servers, services, datatabases, applications, etc.) Colorado based Freshwater Software charged $2,495 for it before (on April, 2003) Mercury bought it and now sells it for $60 per unit (the number of servers multiplied by the number of counters monitored on each machine). So Sitescope monitors can be viewed among other LoadRunner Controller System Resource Graphs: CPU Utilization Monitor DNS Monitor Directory Monitor Disk Space Monitor Log File Monitor Memory Monitor Network Monitor Ping Monitor Port Monitor Script Monitor Service Monitor URL Monitor URL List Monitor URL Sequence Monitor Web Server Monitor WebLogic Application Server Monitor SiteScope is called an "agent-less" technology because it sends native UNIX commands (defined in \SiteScope\templates.os). Sitescope exerts about a 10% overhead on servers responding to remote queries. However, it duplicates the same requests made by LoadRunner's UNIX monitors (hitting servers with twice as much monitoring traffic). Perhaps for this reason the SiteScope monitor has a default measurement update rate of once every 10 minutes. Unless you change this default to 15 seconds (the most frequent allowed), you won't see measurements in Controller graphs. Invoke SiteScope. Click on the name of the monitor. Click on "Edit" next to the Counter name. In the "Update Every" entry, change the value to 15 seconds. Click on the "Update" button to register the change. Linux Status Commands uptime provides an instantaneous summary such as 11:42pm up 18 days, 8:45, 5 users, load average: 0.01, 0.03, 0.07 For the current time, the Number of days up since last boot, the number of users currently logged in, and the load average for the last 1, 5, and 15 minute intervals. The load average (LA) is the average number of processes (the sum of the run queue length and the number of jobs currently running) that are ready to run, but are waiting for access to a busy CPU. Averages from 0 to 1.0 are acceptable for a single CPU. As a general rule of thumb, a machine is being overworked if load averages consistently exceed three times the number of CPUs. top provides load average with auto refresh and additional data (sorted by %CPU): 68 processes: 67 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 12.2% user, 1.6% system, 0.0% nice, 86.1% idle Solaris comes with the prstat command to provide this info. Graphical versions of this include gtop within Gnome and the KDE Process Monitor. Linux Load Average Not Your Average Average by Neil J. Gunther For memory usage, press M. For CPU info, press P. To stop display, enter q. The 'SIZE' field is the total virtual memory size of each process, including all code, data, stack, mapped files, libraries etc. procinfo -fn30 is used to gather system data from the /proc directory every 30 seconds. Last Boot time Load Average average number of jobs running number of runnable processes total number of processes PID of the last process run (idem) Swap info Memory resources Number of disks IRQ info Installed modules (with the -a or -m option) File Systems (with the -a or -m option) xos provides a constantly updated colorful summary view of various components.

Read More......

How does Monitors Work

The objective of LoadRunner is simple; to load an application (set upon a certain environment and hardware), monitor the Servers that is in the environment housing the applications, and lastly collect the results for analysis. LoadRunner sells itself as a load testing tool that is not intrusive in any environment with the capability of not requiring installation of agent programs on the servers in the environment.

How is this achieveable?

What LoadRunner does is to collect information of monitoring counters of the native monitors. Native monitors in this context means the programs/modules that is in-built with the system that you are monitoring. Example of the commons, for monitoring Windows System Resources, LoadRunner draws information from the in-built tool, Perfmon which is available for almost all Windows OS. For Unix System Resources, LoadRunner uses rstatd daemon of Unix OS for monitoring.

To name a few others, for non-System Resources, such as Web Server Resources, Apache Web Servers, the server must be configured to allow monitoring before LoadRunner can draw data out. This applies for Web Application Server (WebLogic, Websphere, etc.) so on and so forth.

For Database Servers, a client is needed to be installed for the monitoring to be successful. Example, for Sybase Database, the Sybase AES client (if I do not remember wrongly) needs to be installed on the Controller;Oracle Databse requires the V$SESSION table to be working. With exception of MS SQL, the counters are in-built into Perfmon.

The list can go on however, the concept of monitoring is the same and applies for other monitors that is not mentioned in the above examples too. (More information of the monitoring requirements can be consulted in the Monitor Reference provided with each installation of LoadRunner.)

Therefore, before any monitoring, the native monitors must be working prior to the test. If the native monitors are not working, the monitoring by LoadRunner will certainly fail. Usually, the monitors failed on the following reasons which I guessed for all load tester should be aware of.

1. No support for the native monitor.
2. Configuration problems on the native monitors.
3. Environmental Issues such as Security, firewall and policies.

A good understanding of the native monitors such as its configuration, type of monitoring data it can provide, and how it generally works will be a good foundation before the load test. This wil be useful for the load tester to relate the required configuration to the System Admin/Engineer, Network Engineers, etc.

In summary, LoadRunner collects monitoring data from the native monitors. Therefore, the native monitors must be configured correctly prior the load test. The reasons for failure could be due to (1) no support, (2) configuration problem and (3) environmental issues.

Hopefully, the above information will be of used to you by serving an understanding of the monitoring requirements needed by LoadRunner.

Read More......