How does the monitoring work in LoadRunner?
Posted: April 22nd, 2008 | Author: TnT Admin | Filed under: Concepts | Tags: LoadRunner, Monitoring | 8 Comments »
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 (anyway, most monitoring tools work in this way). How is this achievable?
What LoadRunner does is to collect information of monitoring counters of the native monitors. Native monitors in this context mean 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.
For non-System Resources, such as Web Server Resources, Apache Web Server, the server must be configured to allow monitoring before LoadRunner can draw monitoring data out. This applies for Web Application Server such as BEA WebLogic and IBM WebSphere. For Database Servers, there is an additional step that requires a client 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 the exception of MS SQL, where the counters are in-built into Perfmon. Client programs that are required to installed also applies to WebLogic JMX Monitoring. 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. Usually, I give myself 1 to 2 days for monitoring setup before the load test.
- No support for the native monitor; Check out the support level on the documentations, knowledge base articles and the support (if the information is not readily available online).
- Configuration problems on the native monitors; Check out and verify the configuration settings on the native monitors against the documentations and knowledge base articles.
- Environmental Issues such as security, firewall and policies; Ensure connectivity between the Controller and monitoring machines (dependent on the port number and how the load testing was implemented) and the access rights given to the load testing user.
A sound understanding of the native monitors (Perfmon, rstatd, etc) such as its configuration, type of monitoring data it can provide, and how it generally works will serve a good foundation before the load test. (Therefore quite a fair bit of reading and googling will do you good!) This will be useful for the load tester to relate the required configuration to the System Admin/Engineer, Network Engineers, etc and get the job done with minimal effort. (You need to talk their “language”!)
In summary, LoadRunner collects monitoring data from the native monitors. This requires the native monitors to be configured properly prior the load test. However, they do fail at times and it’s possible to scope down to either (1) no support, (2) configuration problem and (3) environmental issues that can resolved with adequate planning. Furthermore, a sound understanding of the native monitors will be useful when conveying instructions to the system/network team in configuring them.
very useful
Thank you!
Very nice information for beginners.
Very Useful Info. Thanks alot
I am just a beginner.As per your saying “If the native monitors are not working, the monitoring by LoadRunner will certainly fail”. What do you meant by the native monitors?.And also using LR 8.1 version i was to monitor certain unix servers but not using LR9.1.(with the same machine).I dont know what is causing this.Do you have any idea on this?.
After running a load test, I found that some of the transactions have negative response time. Do you know why?
Myself haven’t bump into such problems yet. Have you contacted support on this? Its an interesting issue to uncover.
Hi,
Onsoft Technologies is conducting a challenging competition to assist the global recession especially for US and UK based testers.
We are exploring options to conduct the competition for BEST TEST PLAN .can you please provide your inputs on the same
here is the rough idea we have brought
1.participants should be any where from the world
2.One Director, two post graduate candidates in software testing with more than 1o+years and at least 5 years in writing test plans
3.The test plan is for SYSTEM TESTING of Decided Webapplication(this will be finalized later)
4.each participant should pay $20 for registration
5.Registration will be allowed only for one month.
6.In June first week the results will be announced
If you or your friends who want to be the director or reviewer please contact us
if you want to participate , please write to us along with your profile
tpchallenge.onsoft@gamil.com
Soon we are launching a website for this then we will update the official information,till then please do not make any payments to anybody
Let me know your comments and views on this
Thanks
ONSOFT Technologies