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 it can be 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 Server, 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 Database 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.
How it can be 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 Server, 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 Database 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.
No comments:
Post a Comment