BEA_Best_Practices_Guide by nirajng

VIEWS: 227 PAGES: 24

More Info


Enterprise Testing and Performance Management Best Practices for BEA Platforms

1325 Borregas Avenue Sunnyvale, CA 94089 tel: 408-822-5200, 800-837-8911 fax: 408-822-5300



“The earlier that customers introduce testing and
performance management in the application lifecycle, the more robust and stable their deployments will be. We’re committed to helping customers improve the return on their application infrastructure investments.” Kenneth Klein Chief Operating Officer Mercury Interactive Corporation



Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Step 1—Preparing the Quality Assurance/Testing Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Step 2—Preparing the Testing Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Step 3—Establishing a Testing Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Step 4—Setting the Testing Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Step 5—Testing Enterprise Java Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Step 6—Conducting Functional Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Step 7—Conducting Performance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Step 8—Using Java HotSpot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Step 9—Using BEA WebLogic Performance Packs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Step 10—Employing Ongoing Performance Monitoring and Management . . . . . . . . . . . . . . . . .16 Taking the Next Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 About Mercury Interactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21




The guide Enterprise Testing and Performance Management Best Practices for BEA Platforms provides a high-level roadmap for bringing Web applications based on the BEA WebLogic E-Business Platform™ into production. Careful testing and optimization in a real-world Web infrastructure help maximize the potential of the most powerful Web servers and applications. This best practices guide describes the 10 most important application-testing steps to follow in order to deploy reliable, high-performing WebLogic-based applications. While the best practices guide is not designed to deliver exhaustive application testing documentation, it will enable you to plan WebLogic application testing, save time and minimize re-work. Mercury Interactive teams with the industry’s leading platform providers, such as BEA Systems, Inc., to help companies deploy and maintain reliable, high-performance Web applications. Mercury Interactive and BEA Systems have worked side by side for more than five years on joint initiatives, and BEA Systems also uses Mercury Interactive tools for its own internal Quality Assurance (QA) stress testing.




Why devote the time and resources to testing when critical deadlines and corporate objectives are pressuring you to launch quickly? There are many reasons: • Testing early reduces cycle time and overall project length • Failure of a mission-critical Web site is costly—in lost revenue, rush charges for emergency fixes, valuable staff time and long-term re-work costs • Testing and performance management assure faster—and higher—returns on investment • Robust, stable platforms reduce the need for intense management and re-work later • Testing assures application performance and functionality under real-world conditions Many people make the mistake of performing only component testing. They limit testing to servers, tiers, devices or software, believing that having “best-of-breed” components results in a highly scalable system. In reality, best-of-breed components do not ensure that your application will scale. When scalability issues arise, organizations tend to add hardware, which often provides only incremental increases in performance (a 2 percent to 5 percent improvement, according to Mercury Interactive’s ActiveTest™ service) and adds unnecessary cost. By leveraging Mercury Interactive’s expertise, you can resolve the vast majority of performance issues (queues, buffer parameters, thresholds and settings) by fine-tuning your application and infrastructure—instead of adding hardware. You can significantly improve application stability, performance and scalability simply by involving Mercury Interactive early in the Web application lifecycle.

To successfully test on the BEA platform, your testing team or QA staff should possess the following skills and knowledge base: • Introductory training for the BEA WebLogic platform—Fundamentals of J2EE Web Application Development Using BEA WebLogic Server from BEA ( • WebLogic Server administration training—BEA WebLogic Server Administration from BEA ( • Ability to test relational database management systems (RDBMS) • An understanding of Structured Query Language (SQL) • An understanding of distributed systems and architecture • An understanding of Web services

Mercury Interactive is experienced with pre- and post-production environments and can help you safely and effectively conduct performance testing in both. In pre-production environments, you can stage and test BEA WebLogic implementations in a dedicated lab environment. Once your lab testing is complete, however, testing in an actual production environment is still recommended.




When testing systems in a production environment, you can use Mercury Interactive LoadRunner® to help you work safely with production data. It offers the option of using simulated data for marking and cleaning, and enables you to switch to a test database. Another option is to use a roll-back mechanism to take a snapshot of the database, overwrite it and then return the database to its original state. LoadRunner makes it easy to parameterize databases and switch them over to do 1-to-1 extrapolation. However, you’ll likely want to test in off-peak periods.

BEA WebLogic Server provides a foundation for many e-business architectures. It is based on a certified implementation of the Java 2 Enterprise Edition (J2EE) specification, enabling scalable, flexible and reliable e-business applications. Although extremely large BEA WebLogic systems may require 10 to 20 machines, using Mercury Interactive solutions doesn’t necessarily require an equivalent quantity of hardware. A properly prepared testing environment will require: • Sufficient server resources to run required LoadRunner virtual users (1 “fast” CPU, and 1 GB RAM for every 1,000 Vusers) • One PC (minimum configuration Pentium 500 MHz, with 128 MB RAM) per functional tester for using WinRunner®, TestDirector® and LoadRunner • Basic Windows requirements • Java Development Kit (JDK) • RDBMS client for automating queries during unit, functional and performance testing • Target browsers (Netscape browsers, Internet Explorer, etc.) • A browser for accessing TestDirector For more detailed information about minimum configurations for BEA WebLogic, visit For information about Mercury Interactive tools, visit

The first step in successful Web application testing is defining requirements. You must first understand what you want to accomplish and then set clear, well-worded goals to achieve accurate test results. Once you define your requirements, you are ready to prioritize them and organize the testing process. Mercury Interactive tests BEA WebLogic applications by first conducting load testing inside the firewall and then conducting stress testing outside of the firewall. In both cases testing begins at the application front end and works toward back-end systems. During performance testing, you will: • Determine the scalability of your infrastructure • Separate the application from the infrastructure and test each separately • Characterize scalability of the application on top of the infrastructure • Develop test scripts • Execute scenarios • Analyze results • Tune scripts and rerun





Clearly articulated and defined requirements are the key to ensuring your testing efforts deliver accurate results. You must first understand what you want to accomplish and set clear goals. Some common goals for testing BEA WebLogic applications include determining: • Number of users you want to accommodate • Maximum throughput you expect from the BEA WebLogic Server • How many transactions you want to be able to execute • Which EJBs should be optimized • Which business processes should be optimized • Ways to ensure acceptable performance of key transactions • Methods for ensuring data integrity and coverage from critical WebLogic business transactions • Which client configurations you expect customers to use for accessing WebLogic applications and preparing to functionally test them

The second step is prioritizing your requirements. What are you going to test and how are you going to know if you’re successful? Because we have tested BEA WebLogic applications so often, we know that time and cost constraints make it impossible to test everything. We can recommend the testing approach that will deliver the best results for the time and resources you have available.

There’s much more to the testing process than recording application bugs and passing them to the development organization to be fixed. Testing today focuses on verifying that Web application design and functionality meet your company’s business objectives, constraints and user requirements. To successfully achieve these goals, a testing methodology requires clearly defined system specifications and application business rules. Test management is a method of organizing the testing process. It ensures that application test assets—requirements, plans, documentation, scripts and results—are developed and maintained for easy accessibility, reusability and instant reporting on testing progress. Organized test management enables you to deliver quality applications in less time. Mercury Interactive’s test management methodology and solution are described in detail in Implementing an Effective Test Management Process (

Mercury Interactive recommends that you allow a minimum of three months for thorough performance testing of WebLogic applications. It is critical to begin testing applications early in their lifecycle, to test rigorously and to supplement application tests with external (outside-the-firewall) testing. Allowing enough time to thoroughly test a Web application actually reduces the total time and cost of ownership of Web systems and applications over their production lives.




If your application uses Enterprise Java Beans (EJBs), then the first step of testing on the BEA WebLogic platform is to test those EJBs for correct functionality. The goal is to ensure each Java Server Page (JSP)/EJB combination functions correctly before it is integrated with the Web application. You can conduct functional EJB testing before the front end of the application is completed. Mercury Interactive’s products enable you to test all EJBs or EJB methods in your WebLogic Server. The second step is to load test EJBs. You can automatically reuse the unit scripts created in step one for load testing. During unit testing, start-and-stop transactions are automatically inserted in the scripts. While not used during unit testing, these transactions become important during functional and performance testing because they enable the scripts to scale for testing thousands of transactions. With Mercury Interactive LoadRunner, you don’t have to modify your scripts later for performance management testing. The goal in load testing is to discover any existing memory leaks and make sure that EJBs can support concurrent processing. Load testing individual EJBs is best done before you undertake end-to-end testing of the entire application.

• Reduce functional defects to zero by checking input and output values of EJBs • Identify maximum transaction load that each EJB can handle • Eliminate memory leaks

During EJB unit testing, you can: • Ensure EJB data integrity by checking incoming and outgoing data • Ensure acceptable EJB and SQL processing data integrity The benefit of data generated during EJB load testing and processing data is that it gives you data for forecasting overall response time for complex processes and, ultimately, the entire application. Load testing enables you to identify and fix functionality now if projected response times are unacceptable. Comprehensive EJB load testing enables you to: • Ensure acceptable JSP, EJB and SQL processing time • Ensure greater application scalability • Eliminate redesign and major re-work later in the process

After JSP and EJB unit testing is completed, the next step is functional testing. This process tests the individually tested components after they are integrated into a WebLogic application or more complex process. Functional testing can begin when your application interface is ready.




With the complexity of commerce transactions and system interactions, it is critical to test for a wide range of business processes. The goal is to assess end-to-end business process integrity and determine whether incoming and outgoing data match expectations. Using Mercury Interactive products, the average automated tester should be able to develop six scripts or six test cases per day.

When regression testing, you can combine Mercury Interactive WinRunner and TestDirector to plan and efficiently execute a series of tests. Test results can be stored in TestDirector’s repository. WinRunner and QuickTest™ Professional can also perform calculation testing, which is critical for verifying accurate e-commerce currency conversions and calculations.

The goal of user interface testing is to ensure that each client interface works correctly with different Java runtime engines (JREs). Using TestDirector, you can plan which user interface configurations will be tested. Next, you will use WinRunner and its Web add-in component to run one test script against all specified client configurations to ensure that your BEA WebLogic application works in all anticipated environments. By combining TestDirector and WinRunner, you can automate testing and track which configurations work and how well they work—as tests are running.

During data integration testing, a series of activities are strung together so that the WebLogic application interactions between multiple systems can be tested. The following are most commonly tested: • Multiple interfaces, such as Web, wireless and client-side • Links that may be broken • Client-interface integration with such back-end processes as submits, updates and deletes • Credit-card system front-end integrations, as well as interaction with outside systems, such as those commonly used in B2B or B2C transactions • Integration of data from old applications into a browser, either by the user entering the data or having it automatically entered by the back-end system

With thorough, accurate functional and regression testing, you can ensure: • Zero functional defects • 100 percent accuracy of arithmetic processing • 100 percent accuracy of data movement along the entire transaction path • B2B transactions operate as expected • Data transfer between systems is correct • Applications are functioning correctly • Customer identification and personalization options work correctly




During functional testing, it is critical to ensure that each application works as expected. If not, it will be impossible to performance test them without breakage. Verifying calculations and currency conversions enables you to hedge risks in financial calculations. Catching errors at this stage can help protect you against losing millions of dollars by the time the system is implemented and the complexity of finding and fixing problems increases significantly. Correct customer identification and personalization options—and their integrity throughout a transaction—ensure that complete customer data is captured. For example, when a user creates an identity using a wireless interface, he must be able to later visit the WebLogic application and be recognized, even if he is using a different client-side interface. Correct functions at this stage eliminate holes in customer data records, ensure that data can be correctly captured for one-to-one marketing uses and reduce the possibility of end-user dissatisfaction. By achieving your functional testing goals, you also ensure the highest probability that your WebLogic application will integrate enterprise-wide without problems.

At this point, all applications and components should have been tested and assembled. Now it’s time to conduct system-level load and performance testing—both inside and outside your firewall. The goal of performance testing is to ensure overall interoperability across servers, applications, networks, hardware, and software as well as: stability, performance, functionality under load, reliability and scalability.
Infrastructure Firewall Users Internet
Load balancers Gateways Web servers Cache servers

System Architecture

ISP bandwidth Routers ISP peering Switches

Application servers Databases Middleware Back office

PHASE 2 (ActiveTest)

PHASE 1 (LoadRunner)

Fig. 1. By first testing Web applications inside the firewall, you can more easily identify potential application problems, without the effects of the Internet. The next step is to test in the real-world Internet environment to ensure that the application can scale to handle unpredictable load and stress factors.

There are two approaches to performance testing. One is to test WebLogic applications in a laboratory environment. Lab testing ensures that your system won’t impact the performance of other production systems. It also gives you full testing control, enabling you to change specific variables and measure the impact of changes. Lab testing provides you with data for predicting how the system will function when deployed. This approach is useful for new applications and systems or when




no other interacting systems exist. The potential downside is that, in a dedicated testing environment, you will have to ignore factors—such as firewalls, geographic locations, large databases, the Internet—that will affect actual performance metrics once the application is deployed. The second approach is to test the system in a real production environment. When the system is deployed in a real environment, you can determine actual performance based on the effects of outside factors. However, it is extremely difficult to control for specific variables and derive reproducible scenarios for improving performance.

A large percentage of application functionality operates in the application server layer, and this is where we can make significant performance improvements. By separating layers and physical tiers in a BEA WebLogic configuration, we can: • Separate thread pools for different functions. This enables us to measure what’s happening so that we can configure the server appropriately. • Test the limits of specific server resources to find this configuration’s maximum load. • Add one functional layer at a time to determine how front-end functions exercise back-end resources. • Based on results, determine how to profile activity for each server.

Application servers are central components of application infrastructures, and they account for more than 20 percent of system processing and response time. Because application servers communicate with many systems that reside behind the firewall (Web server, database, authentication server, etc.), you can analyze them at a granular level to uncover problems with other systems. Problems most commonly occur in the communication and hand-offs between systems and include: • Poor database tuning—Non-optimized queries are sent to the database, creating unnecessary load, poorly configured database connection pools, improperly released database connections and high resource utilization. • Poor cache management—This causes high CPU load due to inefficient garbage collection. Cache management problems are often caused by poorly configured heap size, excessive EJB activation because of sub-optimal cache size, and lack of memory. • Poor session management—This also causes high CPU load. • Poor Web server design—This causes uneven distribution of requests to the application server and bursty load. • Inefficient client request management—This problem depends on thread configuration and processing power.

You can test with your own staff or outsource testing using the Mercury Interactive ActiveTest service. If you conduct your own WebLogic system testing, it’s best to test everything possible with a controlled system inside the firewall. Ideally, it requires one month to create BEA WebLogic testing scripts. Script execution requires approximately two months to test.




If you have limited time, the best approach is to first optimize one component, which simplifies diagnosis of downstream components. For example, using LoadRunner you can load test the database, ensure it is operating at optimal levels and rule it out as a potential performance problem before plugging it back into the system and looking at other elements. By starting first with the largest component, you can systematically rule out or resolve problem areas quickly. Mercury Interactive’s approach allows you to prioritize testing within a tight timeframe and make the most progress.

Stress testing is designed to stress each tier until it breaks. The goal is to ensure that user loads don’t create system downtime or poor reliability or result in high costs. Often, stress testing is conducted over the Internet and outside of the firewall. During stress testing outside of the firewall, the network pipes, load balancing schemes and border routers begin to affect application performance. We approach stress testing using the same methodology as load testing, working from front to back. Successful stress testing depends on accurately describing what you want to test for and then using the appropriate monitors. For example, it requires developing clear objectives and success criteria for response-time testing. In addition, you must establish specific transaction measurements using LoadRunner to simplify results analysis. Formulating a clear definition of reliability can be challenging. LoadRunner measurements can help you define reliability, and then application performance management solutions can manage the user experience after deployment. An important tip during stress testing is to minimize logging and monitoring in LoadRunner so that you minimize the amount of disk space used. Generally, a 72-hour test is best because it can be run unsupervised over a weekend so you do not need to pay staff overtime. Tests that exceed 72 hours result in a huge data set that doesn’t usually deliver incrementally valuable data.

The Java HotSpot™ Server Virtual Machine is a high-performance solution for providing fast, reliable Java technology in the enterprise server environment. Sun Microsystems provides Java HotSpot Virtual Machine for server-side and client-side performance. Both solutions share the Java HotSpot runtime environment but have different compilers suited to the distinctly different performance characteristics of clients and servers. Both solutions deliver highly reliable, secure and manageable environments with greater safety than static compilers. For more information about the Java HotSpot product line, visit

Recent benchmarks from BEA show performance improvements in the WebLogic Server for most workloads when compatible BEA performance packs are used. Performance packs use a platformoptimized (native) socket multiplexer to improve server performance. To use a performance pack,




make sure the NativeIOEnabled attribute of the WebLogic Server element is defined in your config.xml file. The default config.xml file shipped with your distribution enables this attribute by default: NativeIOEnabled=true.

To see which platforms currently have performance packs available: 1. Go to the Platforms Support page at 2. Choose Edit and Find to locate all instances of “performance pack included.” Or scroll down to find your platform under the Platform Certification Detail headline, and look in the Hardware Requirements column.
Element Server ExecuteQueue Server Attribute NativeIOEnabled ThreadCount ThreadPoolPercentSocketReaders (for use when not using nativeIO) Server JDBCConnectionPool AcceptBacklog InitialCapacity MaxCapacity Fig. 2. Performance-related config.xml elements See Tuning Connection Backlog Buffering. See Tuning JDBC Connection Pool Size. For more information See Using WebLogic Server Performance Packs. See Setting Thread Count. See Allocating Threads to Act as Socket Readers.


For more information about using WebLogic Server performance packs, visit

Application performance management is a continuous best practice to ensure that your BEA WebLogic applications deliver maximum functionality and the best possible user experience. Ongoing performance monitoring and management deliver important benefits, including: • Maximizing Web application uptime by proactively monitoring and alerting operations personnel when key performance metrics, such as response time, reach dangerous levels. Proactive alerting enables you to quickly locate problems and speed resolution before end users feel the impact. • Reducing costs by minimizing costs associated with downtime, such as lost revenue, abandoned transactions and customer dissatisfaction. At the same time, performance management enables valuable personnel to spend more time on developing new applications and improving existing ones rather than dealing with a continuous crisis environment. • Allowing you to meet and verify SLAs to customers, managers and lines of business • Extending QA metrics to the complete application lifecycle • Forming the basis for developing effective problem avoidance and resolution strategies • Allowing you to verify and validate previous results • Providing a baseline for measuring ongoing performance and performance-tuning




• Generating invaluable data for budget, hardware, software and staff planning by tracking and recording performance data over time. This ongoing activity allows you to create baselines for application performance. Baselines can be used to define thresholds for alerts in emergency situations and to provide an idea about usage and capacity on your system. If thresholds are being exceeded on a consistent basis, then this might indicate a need to expand or optimize your system. After you make the changes, you can compare the new metrics to your baselines and see how productive the change was. • Establishing a knowledge base for delivering new applications on the same platform, so you know the limits of what you can do or what is needed to achieve specific goals.

Mercury Interactive provides monitoring products and services for: • Monitoring the user’s experience from end to end • Tracking availability and performance of internal network elements • Diagnosing network and system problems rapidly for quick resolution • Capacity planning and baselining • Managing service level agreements (SLAs) with vendors, end users or customers. In addition, performance management can be initiated to help solve intermittent or unresolvable issues that arise, such as: • Inability to gauge the number of users or locations affected by performance problems • End user reports indicating that critical Web applications are unreliable, unavailable or slow when system monitors haven’t alerted you to any problems • When each part of the IT team has “proof” that its systems are not responsible for a particular performance problem • Occasions when it becomes necessary to validate the impact of infrastructure changes on end users • A lack of personnel to implement in-house solutions for application performance management

Performance management often uncovers application problems that may not have surfaced earlier, usually because of the limited amount of time available for conducting thorough testing. Mercury Interactive Topaz™ provides key capabilities needed to successfully manage BEA WebLogic environments. It offers 24x7 visibility into application performance through a variety of charts and views that aggregate data on the end-user experience, response time, alerts and server availability. A manager, CIO or operations team can ascertain application status at a glance and then use these views as the starting point for drill-down and analysis. For example, they can use summary views to quickly determine application performance and availability. To diagnose bottlenecks, they can opt to view detailed performance metrics, analysis tools and drill-down views. Finally, they can use Topaz’s historical data aggregation and flexible reporting capabilities to evaluate trends, baselines and capacity planning.




You can use Topaz for identifying the most commonly found problems, including: • Poor database tuning—Queries are sent to the database in a non-optimal way, creating unnecessary load on the database, poorly configured database connection pools, database connections not being properly released as well causing resources to be consumed unnecessarily. • Poor cache management—This causes high CPU load due to inefficient garbage collection, often caused by poorly configured heap size, excessive activation and passivation of EJBs to and from the cache as a result of sub-optimal cache size configuration, or lack of memory. • Poor session management—This also causes high CPU load. • Poor Web server design—This causes uneven distribution of requests to the application server and bursty load. • Inefficient client request management—This problem depends on thread configuration and processing power.

When problems trigger alerts, the powerful diagnostics in Topaz enable you to minimize downtime. By correlating end-user experience and response time with back-end system performance metrics, Topaz quickly guides you to the cause of the problem. Threshold definitions, alerting options and the ability to correlate key metrics also minimize false alarms. Systems planners also can use Topaz tracking data and usage trends to address changing capacity demands before application performance is adversely affected.

Targeted metrics depend on the specific application being managed. The best results are obtained when the application monitoring team works with application development and QA teams before deployment and understands production goals. Otherwise, if detailed application knowledge is not available, it’s useful to monitor CPU, memory usage, disk activity, database connection parameters, servlet execution times, sessions, threads, EJB usage and exceptions. Choose metrics that correspond to transactions that you define for ActiveAgents—this enables tighter correlation of the end-user experience to back-end monitoring (e.g., for a database-intensive search query, monitor the corresponding JDBC connection parameters; for a .jsp intensive transaction, monitor .jsp execution times). Examples of metrics you can collect from the BEA WebLogic 6.0 platform include: • ExecutionTimeAverage—Average amount of time all invocations of the servlet have executed since created. • OpenSessionsCurrentCount—Current total number of open sessions in this component. • TransactionsCommittedTotalCount—Total number of transactions committed by beans of this home. • TransactionsRolledBackTotalCount—Total number of transactions rolled back by beans of this home. • HeapSizeCurrent—Current size of the JVM heap in bytes. • HeapFreeCurrent—Current amount of free memory in the JVM heap in bytes.




• WaitingForConnectionCurrentCount—Current total waiting for a JDBC connection. • MaxCapacity—Maximum capacity of this JDBC pool. • WaitSecondsHighCount—Number of seconds the longest waiter for a JDBC connection waited. • ActiveConnectionsCurrentCount—Current total active JDBC connections. • ExecuteThreadCurrentIdleCount—Number of idle threads assigned to the queue. • PendingRequestCurrentCount—Number of waiting requests in the queue. Metrics you can collect from the BEA WebLogic 5.0 platform include: • ServerLoginEnable—This value is true if client logins are enabled on the server. • ServerMaxHeapSpace—Maximum heap size for this server, in kilobytes. • ServerHeapUsedPct—Percentage of heap space currently in use in the server. • ServerQueueLength—Current length of the server execute queue. • SeverQueueThroughput—Current throughput of execute queue, expressed as number of requests processed per second. • ServerNumEJBDeployment—Total number of EJB deployment units known to the server. • ServerNumEJBBeansDeployed—Total number of EJBs actively deployed on the server.

You may want to consider conducting performance monitoring and management in-house if: • You have the staff, resources and expertise • You want comprehensive monitoring behind the firewall • You have already invested in in-house application testing Or you may want to consider a managed service, such as Mercury Interactive’s ActiveWatch™. ActiveWatch helps assure continued high performance and enables rapid identification, diagnosis and remedying of performance degradations if they occur. Use a managed service if: • It is not cost-effective to conduct performance management in-house • You don’t have in-house expertise or a dedicated application management staff • You need global monitoring capabilities • You’d like to leverage Mercury Interactive testing and monitoring expertise, especially in designing user transaction scripts

With good testing data and experience gained during the testing lifecycle, you should have a solid base of understanding that will help reduce the time and cost of managing your BEA WebLogic applications. As your business needs change, Mercury Interactive’s performance management solutions and practices can help you quickly adapt to such changes as: platform revisions, new application deployments, new technology additions and changing software or hardware platforms. Mercury Interactive stands ready to help you manage your evolving WebLogic application environment. For more information about Mercury Interactive, our products and services, or to contact a Mercury Interactive representative, visit




Mercury Interactive is the leading provider of enterprise testing and performance management solutions. The company’s automated software and managed services help companies deliver and maintain high-performance applications. Customers worldwide use Mercury Interactive solutions across their application and technology infrastructures to minimize hardware and operational expenses, protect revenue streams and enhance their competitive positions. Mercury Interactive was founded in 1989 and is headquartered in Sunnyvale, California. The company has more than 1400 employees with offices in more than 20 countries. For more information on Mercury Interactive, visit the company’s Web site at


Pre-Deployment Analyzing Results Functional & Regression Testing Analyzing Results Load Testing Inside Firewall Test Planning


Load Testing Outside Firewall Managing Requirements Managing Defects Services Analyzing Results


TestDirector LoadRunner


Astra QuickTest WinRunner XRunner

Astra LoadTest LoadRunner

Diagnosing Root Causes Post-Deployment Identifying Problems

Performance Monitoring Generating Real-time Alerts


TestDirector TestDirector Astra FastTrack Services


ActiveWatch Topaz Post-Deployment ActiveWatch Topaz ActiveWatch Topaz

ActiveWatch Topaz

Fig. 3. Mercury Interactive solutions for the BEA environment address each stage of the application lifecycle.


TestDirector is a global test management solution that supports your manual or automated testing. Requirements, Test Plan, Test Lab and Defects Manager modules integrate seamlessly to support the entire testing process. TestDirector also connects requirements directly to test cases, ensuring that functional requirements have been covered by the test plan. Completely Web-enabled, TestDirector simplifies communication and collaboration among distributed testing teams to accelerate testing cycles.

LoadRunner is a load testing tool that predicts system behavior and performance. It exercises an entire enterprise infrastructure by emulating thousands of users and employs performance monitors to identify and isolate problems. LoadRunner includes support for WebLogic Enterprise Java Beans (EJBs), the WebLogic application server monitor, BEA Tuxedo/Jolt, wireless applications, and streaming media applications.

WinRunner is an integrated, functional testing tool that captures, verifies and replays user interactions automatically. WinRunner enables you to quickly identify application defects and ensure that business processes spanning multiple applications and databases work flawlessly and reliably. WinRunner supports functional testing of Wireless Application Protocol (WAP) applications, transaction verification and simplified test creation.




QuickTest Professional (for Java)

QuickTest Professional is an icon-based tool that automates the functional and regression testing of dynamically changing Web applications. Its ActiveScreen technology offers the shortest learning curve in the industry while allowing users to create reusable, easy-to-maintain and comprehensive tests for browser-based and Java-based applications and ERP/CRM solutions.

ActiveTest is a hosted, Web-based testing service that conducts full-scale stress testing of Web applications. It can emulate the behavior of millions of customers using a Web application to identify bottlenecks and capacity constraints before they affect end users. ActiveTest includes support for streaming media and wireless applications and gives you the power to test from outside your firewall.

The Topaz product suite measures end-user experiences and correlates performance issues to their root causes in a Web infrastructure. Topaz monitors application performance both inside and outside the firewall, enabling IT professionals to maximize Web application performance, protect revenue streams, reduce IT costs by minimizing problem resolution time, evaluate infrastructure changes by measuring their impact on the end-user experience, and define and enforce service level agreements.

ActiveWatch is Mercury Interactive’s 24x7 managed service that accurately measures a Web site user’s experience from various points across the globe. Robust and redundant, Mercury Interactive uses ActiveWatch to monitor performance of its own sites.

ActiveTest, ActiveWatch, QuickTest and Topaz are trademarks, and LoadRunner, TestDirector, WinRunner, Mercury Interactive and the Mercury Interactive logo are registered trademarks of Mercury Interactive Corporation. All other company, brand and product names are marks of their respective holders. © 2001 Mercury Interactive Corporation. Patents pending. All rights reserved. 384-BR-BEABP


To top