Loadrunner monitoring vs local monitoring
1. What version of LoadRunner (LR) or PerformanceCenter (PC) are you using? LR 9.10
2. What is the protocol you are recording?
Web and Http
2.3 If OracleNCA with Oracle Forms Server, please list the version of Oracle Forms Server.
3. If HTML - are you using HTML-Advanced with URLs or,
4. If URL mode:
- Concurrent groups, or
- Without Concurrent groups?
Without Concurrent groups
5. Which LoadRunner/PerformanceCenter feature (FPs) or service packs are you using?
6. VuGen Recording - are you using Old or New Recording Engine?
7. List here the Licensed Vuser type/ quantity that you are/were using for this specific issue /problem.
8. Is your support/maintenance contract current and active?
current and active
9. What platform(s) (PCs) and Operating Systems (Windows-XP, etc.) are being used for load generators and controllers? Include version and service packs (SP1 or 2, etc.)
10. If you have filed a service request with HP/Mercury, what have they told you at this point with respect to your issue?
What is the general opinion of this forum regarding the use of loadrunner and rstatd agents to monitor environment servers as opposed to monitoring using native or third-party tools directly on the boxes?
Is using loadrunner monitors generally more frowned upon?
I've used both appoarches and each offers its advantages and disadvantages. Any thoughts?
-- consolidated and centralized reports
-- Readily available graphs and reports
-- Need machine with enough horsepower for processing data
-- Need network bandwith to transfer data back to controller
-- Direct and local data analysis
-- More options and tools available
-- Data may need to be massaged(Excel)
-- More complex data collection process may be involved
Re: Loadrunner monitoring vs local monitoring
Your plus/minus list agrees with my own experiences. I prefer to use the LR-native monitors with rstatd, unless with SSH2 I can use SiteScope (SS). LR native monitors are SS. If what I hear from the various opinions collected from Mercury then HP; SS was unbundled and as a separate product imporved beyond LR-Native or SS as found in LR-Native. Clearly this move was intended to generate more $$. That's just business.
Regarding rstatd or any Unix command beginning with "r"; some regard those commands as highly hackable and therefore discourage or prevent usage. I do not know how much credence to lend to that notion.
SS's advantages are that the commands issued to collect server health data are highly configurable, and - one can also create your own custom shell scripts to upchuck server health info.
Note! There is evidence to suggest that LR-Native and SS are sometimes baffled by LPARs. This was also an issue in OpenView and then fixed in version 6.x (x = ??).