This chapter covers the following:
Application Replay enables realistic testing of planned changes to any part of the application stack from application server down to disk, by re-creating the production workload on a test system. Using Application Replay, you can capture a workload on the production system and replay it on a test system with the exact timing, concurrency, and transaction characteristics of the original workload. This enables you to fully assess the impact of the change, including undesired results, new contention points, or plan regressions. In addition, extensive analysis and reporting is provided to help identify any potential problems, such as new errors encountered and performance divergence. Types of changes that can be tested with Application Replay include application server upgrades, hardware updates, O/S changes, configuration changes, and so on. Capturing real-world production workload eliminates the need to develop simulation workloads or scripts, resulting in significant cost reduction and time savings. By using Application Replay, realistic testing of complex applications that previously took months using load simulation tools can now be completed in days. As a result, you can rapidly test planned changes and adopt new technologies with a higher degree of confidence and at lower risk.
Today's enterprise application deployments are highly complex and, therefore, challenging to manage. They comprise multiple tiers, such as Web servers, application servers, and databases, running on multiple hosts. Their software architecture combines multiple independent components, such as client-side user interfaces, business logic and data access mechanisms, in addition to stateful client-server protocols typically built over HTTP.
Due to the complexity of these structures, predicting the behavior of the entire stack in a production environment is extremely difficult. Given the complexity of these deployments, and the absence of system-wide verification techniques, effective testing is critical to ensuring successful deployment after an infrastructure change.
The Application Replay feature provides a testing structure that works by first capturing the entire workload relevant to an application (as generated by the application's Web interface) at the production site.
The captured application workload is then moved to the test environment, where the replay driver infrastructure on one or more hosts, reproduce the captured workload, preserving its original properties, such as concurrency and request timings.
Finally, extensive performance and correctness data from all layers of the stack is collected and reported. This enables you to compare the replay with the original captured workload. In this way, any issues resulting from infrastructure changes that occurred during the replay can be identified, and appropriate troubleshooting action undertaken to prevent them from occurring in production. Moreover, it increases your confidence in a successful deployment.
The use of real workloads offers a number of significant advantages over testing techniques based on synthetic workloads. In particular:
It provides a system-wide perspective starting from the user's activity. This is in contrast to the traditional piecemeal testing of individual components that provides little information on their combined behavior and performance under a realistic workload.
Rather than relying on pre-determined scenarios, the use of real workloads provides comprehensive testing, subjecting the system to real users operations. For Web applications, this not only means exploring all possible ways a user interacts with the system, but also all possible load conditions. This is necessary because systems behave quite differently under different workload characteristics (for example, the number of concurrent users).
Far greater insight is obtained into possible errors. Test results include data for every layer of the stack, and these can be correlated across different layers. Besides performance, it also provides a means to verify correct execution, by checking for errors or unexpected server responses.
In order to capture Web application workloads, Application Replay uses Oracle Real User Experience Insight (RUEI). This is a Web-based utility to report on real-user traffic requested by, and generated from, your Web infrastructure. It measures the response times of pages and user flows at the most critical points in your network infrastructure. It provides you with powerful analysis of your network and business infrastructure, while an insightful diagnostics facility allows application managers and IT technical staff to perform root-cause analysis.
Typically, RUEI is installed before the Web servers, behind a firewall in the DMZ. The data collection method is based on Network Protocol Analysis (NPA) technology. This data collection method is shown in Figure 3-1.
Figure 3-1 How RUEI Collects Data
When an object is requested by a visitor, RUEI sees the request and starts measuring the time the Web server requires to present the visitor with the requested object. At this point, RUEI knows who requested the page (IP client), which object was requested, and from which server the object was requested (IP server).
When the Web server responds and sends the object to the visitor, RUEI sees that response, and stops timing the server response time. At this stage, RUEI can see whether there is a response from the server, whether this response is correct, how much time the Web server required to generate the requested object, and the size of the object.
RUEI is also able to see whether the object was completely received by the visitor, or if the visitor aborted the download (proof of delivery). Therefore, RUEI can determine the time it took for the object to traverse the Internet to the visitor, and can calculate the Internet throughput between the visitor and the server (connection speed of the visitor).
Further information about RUEI is available from the following location:
This section describes the requirements that must be met, and the issues that should be considered, in order to use the Application Replay facility for workload capture and replay. It is strongly recommended that you carefully review this information before proceeding with a workload capture.
It is strongly recommended that you review the Oracle Support Web site to obtain up-to-date information about supported RUEI, application server, and database versions, as well as patches, configurations, known issues, and workarounds.
This section covers the following:
In order to use RUEI to capture your application workloads, you must ensure that:
RUEI version 12.1 (or higher) has been configured to monitor the required applications. See the Oracle Support Web site (
http://www.oracle.com/support/contact.html) for information about required releases and hot fixes. Information about deployment options and requirements is available from the Oracle Real User Experience Insight Installation Guide.
You have a valid user name and password combination. If necessary, contact your RUEI Administrator. Note that the user account must have Security Officer permission. For further information about roles and permissions, see the Oracle Real User Experience Insight User's Guide.
You have the URL used to access the RUEI installation. If necessary, contact your RUEI Administrator.
The configured RUEI logging and masking policies are consistent with the use of Application Replay. This is described in the following section.
RUEI Configuration for Application Replay
As mentioned above, you must ensure that the RUEI logging and masking policies are configured as follows:
For further information on these configuration procedures, see Chapter 13 "Managing Security-Related Information" of the Oracle Real User Experience Insight User's Guide.
The following Enterprise Manager privileges must be assigned to users of the Application Replay facility:
ASREPLAY_VIEWER in order to view captures, replays, and replay tasks.
ASREPLAY_OPERATOR in order to create, modify, or submit captures, replays, and replay tasks.
To assign these privileges, find the resource type named Application Replay Entities, then click the pencil icon to add the above privileges.
In addition to the above, users must also be assigned the
PERFORM_OPERATION_ANYWHERE (Execute Command Anywhere) privilege.
In order for database users to run the Application Replay facility with database capture, the following privileges must be granted to the user:
GRANT ADMINISTER ANY SQL TUNING SET TO asreplay; GRANT EXECUTE ON DBMS_LOCK TO asreplay; GRANT EXECUTE ON DBMS_WORKLOAD_CAPTURE TO asreplay; GRANT EXECUTE ON DBMS_WORKLOAD_REPLAY TO asreplay; GRANT CREATE SESSION TO asreplay; GRANT CREATE ANY DIRECTORY TO asreplay; GRANT SELECT_CATALOG_ROLE TO asreplay; GRANT BECOME USER TO asreplay; GRANT DROP ANY DIRECTORY to asreplay;
Note that in the above example, the database user is assumed to be called
Before a workload can be replayed, the logical state of the application data on the replay system should be similar to that of the capture system when replay begins. Therefore, you should have a strategy in place to restore the application server and database state on the test system. To restore the application server state, you should consult your application administrator. To restore the database state, consider using one of the following methods:
Recovery Manager (RMAN)
DUPLICATE command. For further information, see the Oracle Database Backup and Recovery User's Guide.
Snapshot standby. For further information, see the Oracle Data Guard Concepts and Administration.
Data Pump Import and Export. For further information, see the Oracle Database Utilities.
Determine and set up the directory where the captured workload will be stored. Before starting the capture, ensure that the directory has sufficient disk space to store the workload. If the directory runs out of disk space during a capture, the capture will be terminated.
To estimate the required disk space, it is recommended that you run a test capture on your workload for a short duration (typically, a few minutes), and then use this to extrapolate the space required for a full capture. To avoid potential performance issues, you should also ensure that the target replay directory is mounted on a separate file system.
Figure 3-2 shows the architecture of the Application Replay facility.
Figure 3-2 Application Capture and Replay Architecture
The capture part of Application Replay operates within the context of a production environment. This deployment comprises Web and application servers, and a database. The Web-tier capture mechanism is provided by RUEI. It writes information about the monitored traffic to capture files. These contain HTTP requests, responses, and timings, along with all other data necessary to accurately reproduce the production workload against a test system. Once the capture is complete, the generated files constitute a complete representation of the entire production workload.
The replay part of Application Replay operates within the context of a test system. This comprises an application stack that runs the system configuration under test. One or more Replay Clients reproduce the captured workload, preserving its original properties, such as concurrency and request timings. Further, the Application Replay facility uses synchronization to ensure that each replayed request sees the exact application state it saw during capture so that the responses are directly comparable. Finally, it collects a wealth of performance and verification data from all layers of the stack, and allows you to compare the replay with the original capture upon which it is based.
Depending on the volume and concurrency of the workload capture, it may be necessary to deploy multiple Replay Clients, each assigned a portion of the workload. Recommendations about required Replay Clients based on the captured workload are available when scheduling a replay.
To create an application workload capture:
Figure 3-3 Application Replay Page
Figure 3-4 Create Capture (Overview) Page
Figure 3-5 Create Capture (System) Page
Figure 3-6 Create Capture (RUEI Application) Page
Click Show Applications to view the applications currently being monitored by the specified RUEI deployment. Note that you can use the traffic information available for each application to determine its suitability for capture. In particular, when selecting the applications to be included in the capture, you should ensure that the applications are running, and traffic volumes and error levels are within acceptable bounds. When ready, click Next. The page shown in Figure 3-7 appears.
Figure 3-7 Create Capture (Database) Page
Figure 3-8 Create Capture (Storage) Page
Capture files can require large amounts of disk space. Therefore, it is recommended that you perform a short capture, and then use that as the basis for calculating the required disk space for the planned capture. In addition, be aware that the generated capture files are in a proprietary format, and should not be modified.
Click the Select Target icon. A new window opens that allows you to view the available targets. Click a target to select it. Note that only one host target can be selected. You can use the Target Type menu to restrict the listing of targets to specific types. Note that it is also recommended that you review the status of the selected targets, and ensure that they will be available throughout the planned capture. Specify the credentials of the selected storage host. When ready, click Next. The page shown in Figure 3-9 appears.
Figure 3-9 Create Capture (Schedule) Page
If the capture is configured to run indefinitely, it must be stopped manually from the Capture Page. It is strongly recommended you regularly check the size of the created capture to prevent running out of storage space.
Figure 3-10 Create Capture (Review) Page
Once a capture has been started, you can monitor the capture process to ensure that the intended traffic is being correctly captured, and that the application system is working under normal conditions. An example of a capture progress report is shown in Figure 3-11.
Figure 3-11 Capture Page
Be aware that there is a lead time of approximately 10 minutes after the start of a capture before progress information about it becomes available. This is available from the Application Replay page (Figure 3-3). In either case, the characteristics of the capture are detailed in terms of its volume, performance, and errors. In this way, you can assess the quality of the capture, and its usefulness for testing purposes.
Note that the number of requests monitored during the capture process is particularly useful for assessing the capture's progress. In the event of an unusually high level of errors, you can use the Job page (available by clicking the RUEI Capture Job setting) to drill-down into specific errors.
You can replay a workload capture against a test system. Besides issuing identical HTTP requests, the replay mechanism also mimics the characteristics of the capture in terms of concurrency and timing. This section provides information about the following parts of the replay process:
Proper planning of the workload replay ensures that the replay will be accurate. Replaying a workload capture requires the following steps:
Ensure that the application data state on the test system is logically equivalent to that of the capture system at the start time of workload capture. This is described in "Setting up the Test System Database for Application Replay".
All references to external systems have been resolved. This is explained in "Resolving References to External Systems for Application Replays".
It is important to understand that a replay is an execution (playback) of a workload capture. A replay task is a group of replays based on the same capture. After a replay is completed, you can view a replay report and compare the replay with the initial capture, or create another replay within the same replay task. Typically, the replays within a replay task perform the same purposes. For example, a database or host system configuration with multiple parameter changes.
It is recommended that replays be grouped into the same replay task in order to facilitate comparison. For example, replays that relate to the testing of the same database upgrade patch should be grouped into the same replay task.
A captured workload may contain references to external systems, such as database links or external tables. It is critical that you reconfigure these external interactions to avoid impacting other production systems during replay. Typical external references that need to be resolved before replaying a workload are shown in Table 3-1.
Table 3-1 References to External Systems
Typically, it is not desirable for the replay system to interact with other databases. Therefore, you should reconfigure all database links to point to an appropriate database that contains the data needed for replay.
All external files specified using directory objects referenced by external tables need to be available to the database and application server during replay. The content of these files should be the same as during capture, and the filenames and directory objects used to define external tables should also be valid.
You should reconfigure any references to directories on the production system by appropriately redefining the directory objects present in the replay system after restoring the database.
URLs/URIs that are stored in the database and application server need to be configured so that Web services accessed during the capture will point to the appropriate URLs during replay. If the workload refers to URLs that are stored in the production system, you should isolate the test system network during replay.
To avoid resending E-mail notifications during replay, any E-mail server accessible to the replay system should be configured to ignore requests for outgoing E-mails.
To avoid impacting other production systems during replay, it is strongly recommended that you run the replay within an isolated private network that does not have access to the production environment hosts.
URLs in the workload capture files need to be remapped to different values before replay within the test environment. For example, the Web application URL in every request needs to be remapped to that of the test system.
Note that wildcard characters are not supported within remapped URLs. All required domain and port numbers must be fully specified.
The RUEI installation monitoring your network traffic can be configured to omit the logging of sensitive information. This is called masking, and prevents passwords and other sensitive information from being recorded on disk. Further information on the use of this facility is available from the Oracle Real User Experience Insight User's Guide.
It is important to understand that Application Replay only supports the substitution of one value for each masked field. For example, if an application logon password field is masked, you will need to set up one common alternative logon password for all user accounts in the test system.
To replay a workload capture using Enterprise Manager:
Figure 3-12 Create Replay Task Page
Figure 3-13 Create Replay (Overview) Page
Figure 3-14 Create Replay (System) Page
Figure 3-15 Create Replay (Capture Storage Credential) Page
Figure 3-16 Create Replay (Replay Clients) Page
Figure 3-17 Create Replay (Synchronization) Page
Figure 3-18 Create Replay (URL Mappings) Page
Figure 3-19 Create Replay (Masked Data Substitution) Page
Figure 3-20 Create Replay (Additional Replay Parameters) Page
Figure 3-21 Create Replay (Schedule) Page
Detailed information about a selected replay is available by clicking it within the Application Replay Page. An example of a replay overview is shown in Figure 3-22.
Figure 3-22 Example Replay Summary
It consists of three parts:
Home: provides a overview of the replay, its associated replay task, and the capture upon which it based. The progress of the replay, and a comparison with the original capture, is also provided.
Results: provides more detailed information about the request divergence. This includes a comparison of page performance during the original capture and the replay, and the application pages that experienced the highest level of divergence. An example is shown in Figure 3-23.
Within this section, The Page Analysis section allows you to perform an analysis of each application page across selected metrics. The Divergences section allows you to view information restricted to specific divergence types (such as access, content, and so on). The Charts section allows you to view detailed replay information across specific metrics (such as average page load time).
Review: provides information about the replay environment (such as the credentials, host, and replay clients), as well as the URL mappings and masked data substitutions used during the replay.
Figure 3-23 Example Replay Results Summary
Using the Oracle Application Testing Suite's OpenScript module, you can further analyze divergence errors by viewing them by session. Currently Application Replay calculates divergence statistics and presents them on a per page basis. Enterprise Manager allows you to export this session data to a .
zip file and import this data into OpenScript.
Creating a Session .zip File
The session .
zip file generated from Enterprise Manager contains both capture and replay data.
To create a .
Navigate to the Replay Divergence Page.
Choose View by Session as the viewing Mode.
In the Sessions list, click on the Session ID that contains divergences (shown in the Divergences column). The Session Divergence Detail dialog appears.
In the Pages region, click Fetch Page Details.
In the Export Session Data region, click Export.
Once the export operation is complete, a link to the session data .zip file appears.
Click on the link to download the session data .zip file and save the file to your local system.
Importing a Session .zip File into OpenScript
Once you have created a .zip file containing the capture and replay data, you must import this data into OpenScript.
To import the contents of the .zip file:
From the File menu, select New. The New Project dialog displays. From here, you can choose a wizard to create a new Load Testing script.
zipfile you created earlier, select the file and click Open.
This section provides guidance on dealing with the most common problems encountered when capturing and replaying workloads. In addition, it is recommended that you review the Oracle Support Web site for information about known issues and workarounds. It is available at the following location:
Ensure that the RUEI installation used to monitor the applications in the workload capture meets the following requirements:
Check the Oracle Support Web site for information about supported versions and required hot fixes.
Make sure RUEI has been configured to monitor the required applications. Information about deployment options and requirements is available from the Oracle Real User Experience Insight Installation Guide.
Make sure you have a valid user name and password combination. If necessary, contact your RUEI Administrator. Note that the user account must have Security Officer permission. For further information about roles and permissions, see the Oracle Real User Experience Insight User's Guide.
Ensure Full-Session Replay (FSR) has been enabled, and sufficient storage has been assigned, for each application that is planned to be captured. In addition, you should ensure that each application's data replay logging and masking settings are compatible with the use of FSR. For information, see the Oracle Real User Experience Insight User's Guide.
Ensure that your Web server has been configured to use static SSL certificates. This is necessary because RUEI does not support dynamic SSL certificates.
If your application make use of jumbo frames, increase the RUEI capture length from its default 2kb to 64kb by issuing the following command on the RUEI Reporter system as the
execsql config_set_profile_value wg System config CaptureLength replace 65536
In addition to the requirements indicated above, you should also ensure that:
RUEI is correctly capturing all required traffic using the appropriate logging and masking policies. For information on verifying its configuration, see the Oracle Real User Experience Insight User's Guide available at the following location:
The database host user ID belongs to the same group as the Enterprise Manager Agent user account.
In addition to the requirements indicated above, you should also ensure that:
All required URLs have been correctly remapped, as described in Remapping URLs for Application Replays. Check whether the test system has been configured as HTTP or HTTPS, the domain name of the Web server, and the relevant port number. In addition, verify that the full domain name is specified in the URL, and not just the host name.
It is strongly recommended that you do not replay a captured workload in a production environment.
Ensure that you have provided a substitute value for all sensitive data fields that were masked during capture. This is described in Substituting Sensitive Data for Application Replays.