Synthetic monitoring (also known as active monitoring) is website monitoring that is done using a web browser emulation or scripted real web browsers. Behavioral scripts (or paths) are created to simulate an action or path that a customer or end-user would take on a site. Those paths are then continuously monitored at specified intervals for performance, such as: functionality, availability, and response time measures.
Synthetic monitoring is valuable because it enables a webmaster to identify problems and determine if his website or web application is slow or experiencing downtime before that problem affects actual end-users or customers. This type of monitoring does not require actual web traffic so it enables companies to test web applications 24x7, or test new applications prior to a live customer-facing launch. This is a good complement when used with passive monitoring to help provide visibility on application health during off peak hours when transaction volume is low.
Because synthetic monitoring is a simulation of typical user behavior or navigation through a website, it is often best used to monitor commonly trafficked paths and critical business processes. Synthetic tests must be scripted in advance, so it is not feasible to measure performance for every permutation of a navigational path an end-user might take. This is more suited for passive monitoring.
Synthetic testing is useful for measuring availability and response time of critical pages and transaction (how a site performs from all geographies) but doesn't monitor or capture actual end-user interactions. This is also known as Active monitoring that consists of synthetic probes and web robots to help report on system availability and predefined business transactions.
Performance Testing
"Performance engineering is the process by which software is tested and tuned with the intent of realizing the required performance. This process aims to optimize the most important application performance trait, user experience."
Sunday, December 4, 2011
Monday, April 18, 2011
LoadRunner 9.51 Controller Error - Cannot Initialize Driver DLL
If you are getting the "Cannot Initialize Driver DLL" error, cross check your system configuration with the System Requirements in Readme document.
Cross check the currently logged in user rights and give the Administrtor/ right to create services, etc previlages, reboot your machine and try again.
Labels:
Cannot Initialize Driver DLL,
Controller
Friday, April 1, 2011
How to recover failed result?
If a load test completes or is stopped either manually or because of some failure during the test, but the result collation process fails, is it possible to recover the result data?
Yes, you can... see the below solution
Yes, you can... see the below solution
Solution
Try the Collate option (Controller -> Results -> Collate Results)
First, try the Collate option: Controller -> Results -> Collate Results. If this fails, then,
1. On the controller machine, go to Result -> Results setting to verify the result location.
2. Navigate to the result directory on the controller.
3. Locate the file named remote_results.txt and open it in any word editor
4. On remote_results.txt, you will see the location of the .eve file on remote host. For example
MyHost=c:\temp\brr1\netdir\test\myhost_1.eve
5. Go to that specific host, and copy of the .eve file to the controller machine's result directory.
6. Open the Result file ( .lrr) in Analysis .
If the scenario crashed, or ended prematuerly then set "FullData=1" in the lrr file of the result folder:
1. Open the Result file ( .lrr) in notepad
2. Search for the [Data Collection] section
3. Create/modify the value or FullData to 1
Example:
[Data Collection]
FullData=1
This will help in cases that the result files ( *.eve) contains useful data but the Controller did not manage to write to the lrr that it has the data. FullData will be zero in this case. Setting it to 1 will enable you to view what data was saved.
If the result still failed to come up, it is very likely that the _t_rep.eve file in the controller is not completely generated. In order to save what can be saved, run the scenario again, for a short interval(5 mins) saving the results in a folder different than the old results folder. The _t_rep.eve file and the .lrr file in the new result directory need to be edited. In the _t_rep.eve file there is a line (first one) which maybe something like this:
"28 11 1018300521 2 4627103 22735576 5481115"
The 11 is the event code for start scenario.
The 1018300521 is the start time and it needs to be moved backward to match the beginning of the first load test.
The same must be done for the scenario start time specified in the .lrr file. For example,
[Scenario]
Start_time=1018300521
Put here the same number.
After this replace the binary eve files(.eve or .gzl) from the new load test result with the ones collected from the LoadGenerators resulted from old scenario run. Back up the data folder in the new results directory. Copy the data folder from the old results directory in the new results directory. Now the results can be analyzed.
If the exact time of start of the first load test is not known. Select any start time that will definitely fall before the estimated start time of the original scenario. For eg; say 10000 seconds less than the one in the new load test. Make a few iteration until you find out what exactly was the first event's time.
Note: The duration of scenario in the new result will not be accurate.
It is advised not to overwrite the old result directory in these cases since it consists of the summary data and the monitoring data created even before collation.
Labels:
Load Runner,
LR Controller,
Performance
Friday, February 11, 2011
OBIEE Overview
OBIEE comprises powerful BI server technology and BI presentation tools - referred to as Oracle BI Enterprise Edition (OBIEE) - and supplements them with specialty BI reporting tools secured in the Hyperion acquisition (Plus). Together, these technologies offer significant business intelligence functionality to enable the insight driven enterprise.
OBIEE is an integrated suite sharing a common service-oriented architecture; common data access services; common analytic and calculation infrastructure; common metadata management services; a common semantic business model; a common security model and user preferences; and common administration tools. It is designed to provide mission-critical scalability and performance with data source specific optimized request generation, optimized data access, advanced calculation, intelligent caching services, and clustering.
OBIEE consists of several interdependent components, with the Oracle BI Server at its core.
§ Oracle BI Server — a highly scalable, highly efficient query and analysis server that integrates data via sophisticated query federation capabilities from multiple relational, unstructured, OLAP, and pre-packaged application sources, whether Oracle or non-Oracle.
§ Oracle BI Answers — a powerful ad-hoc query and analysis tool that works against a logical view of information from multiple data sources in a pure Web environment.
§ Oracle BI Interactive Dashboard — rich, interactive pure Web dashboards that display personalized information to help guide users in effective decision making.
§ Oracle BI Publisher — a highly scalable reporting engine capable of generating reports from multiple data sources in multiple formats via multiple delivery channels.
§ Oracle BI Briefing Books — reports that capture a series of snapshots of an Oracle BI Dashboard or report allowing the information to be viewed offline presentation style.
§ Oracle BI Disconnected Analytics — a packaged solution to offer Answers and Dashboards to mobile professionals on computers disconnected from the network.
§ Oracle BI Office Plug-In — automatically synchronizes information from Answers to Microsoft Word, Excel, and PowerPoint.
§ Oracle BI Delivers — an alerting engine to capture and distribute notifications via multiple channels in response to predefined business events to speed decision making.
Ø Oracle Answers is the only report building interface that OBIEE provides
Ø It is used for the construction of both Queries (the data) and Reports (the presentation)
Ø Dashboards are simply containers for reports and other content
Ø Native connectivity for sources such as Oracle, DB2, Teradata, SQL Server etc. Uses ODBC for MS Access
Dashboards
§ Dashboards are the standard interface for the majority of Users
§ It allows multiple reports to be displayed in a tabbed interface
§ The reports are interactive – they can be clicked on to interact with the data
§ Ideally highly summarized and graphical
§ Analytics allows a dashboard or report to be exported to
o PDF
o HTML
o Downloaded to Excel or CSV
Main components of Answers page
§ The Answers Web Catalog
o Store reports, dashboards, filters, prompts
§ The BIS Presentation Layer
o Read directly from the BIS server, these are the areas that you can work in
o Subject Area – Consists of data elements/fields that answer certain business questions.
§ Select a Subject Area to build a query or a report
§ Applications and Administration links
o Other portions of the Analytics environment
§ Exporting
o Results from Answers can be exported to PDF, HTML. Can also be Printed or Downloaded to Excel, CSV, MHTML
Labels:
OBIEE Load Test,
OBIEE Overview,
Performance Testing
Friday, February 6, 2009
Performance Engineering
"Performance engineering is the process by which software is tested and tuned with the intent of realizing the required performance. This process aims to optimize the most important application performance trait, user experience."
Labels:
Load Test,
Performance,
Stress Test,
Testing
Subscribe to:
Posts (Atom)