Examining Results from the Baseline Applications

The following sections provide information about baseline applications:

 

MedRec Benchmark Overview

The MedRec sample application was used for the Light and Heavy-weight application tests. The difference between the Light and Heavy-weight application tests is the communication protocol used between client and server. For the Light-weight application test, the HTTPS 1.1 protocol is used from the clients. For the Heavy-weight application test, the HTTPS 1.1 protocol is used, which involves secure/encrypted data communication between client and server.

Avitek Medical Records (or MedRec) is a WebLogic Server sample application suite that concisely demonstrates all aspects of the J2EE platform. MedRec is designed as an educational tool for all levels of J2EE developers; it showcases the use of each J2EE component, and illustrates best practice design patterns for component interaction and client development.

The MedRec application provides a framework for patients, doctors, and administrators to manage patient data using a variety of different clients. Patient data includes:

  • Patient profile information - A patient's name, address, social security number, and login information.
  • Patient medical records - Details about a patient's visit with a physician such as the patient's vital signs and symptoms as well as the physician's diagnosis and prescriptions.

The MedRec application suite consists of two main J2EE applications. Each application supports one or more user scenarios for MedRec:

  • medrecEar - Patients log in to the patient Web Application (patientWebApp) to edit their profile information, or request that their profile be added to the system. Patients can also view prior medical records of visits with their physician. Administrators use the administration Web Application (adminWebApp) to approve or deny new patient profile requests. medrecEar also provides all of the controller and business logic used by the MedRec application suite, as well as the Web Service used by different clients.
  • physicianEar - Physicians and nurses log in to the physician Web Application (physicianWebApp) to search and access patient profiles, create and review patient medical records, and prescribe medicine to patients. The physician application is designed to communicate using the Web Service provided in medrecEar.

The medrecEAR application is deployed to a single WebLogic Server instance called MedRecServer. The physicianEAR application is deployed to a separate server, PhysicianServer, which communicates with the controller components of medrecEAR by using Web services.

 

Changes to MedRec and Transactions Used for Benchmarking

For capacity planning benchmarking purposes, the WebLogic Server 8.1 MedRec application has been optimized. The patient registration process was made synchronous and two-phase commit is omitted in the modified application. The client running the LoadRunner benchmarking software is used to generate the load using the following sequence of transactions:

  1. A patient connects to the MedRec application and opens the Start page.
  2. The patient completes the registration process.
  3. A physician connect to the online system and signs in.
  4. The physician performs a lookup for a patient.
  5. The physician creates a new visit for the patient, creates and deletes prescriptions.
  6. The physician logs out.
  7. A patient signs in and edits the user profile.
  8. The patient makes changes to her profile and updates the information.
  9. The patient logs out.

Each action in the sequence above is treated as a transaction for computing the throughput. For each client, a unique patient ID is generated for every iteration.

 

Overview of the Baseline Applications

BEA produced baseline capacity planning results as a starting point. These baseline numbers were generated using three different applications:

  • Light application software - MedRec application consisting of search, select, insert, and update transactions using the HTTP protocol.
  • Heavy application software - MedRec application consisting of search, select, insert, and update transactions using the HTTPS (secure) protocol.

You can use the metrics provided for each of these applications to set the expectation about WebLogic Server throughput, response time, number of concurrent users, and overall impact on performance based on customer choice of hardware and configuration.

The measurements in the systems under study were captured without adding a think-time factor to the transaction mix.

Note: For a capacity planning profile using the WebAuction application on standard hardware, see Chapter 15, "Analysis of Capacity Planning," in J2EE Applications and BEA WebLogic Server, Prentice Hall, 2001, ISBN 0-13-091111-9 at http://www.phptr.com.

 

Configuration for MedRec Baseline Applications (Light and Heavy)

For all measurements, the client applications and the Oracle database were kept on a 4x400 Mhz Solaris processor. A WebLogic Server intance was started on each processor/configuration combination listed. Baseline numbers from the capacity measurement runs for each of three applications are listed in tabular form, after the description of the application.

The baseline numbers were collected using a three-tier configuration, separating the client applications (running LoadRunner benchmarking software), WebLogic Server containing the MedRec baseline application, and the Oracle database server. The database in the systems under study is an Oracle 8.1.7 database. All measurements were taken using a 1 GB network.

Figure 2-1 Three-Tier Configuration


Three-Tier Configuration


 

WebLogic Server Configurations

The baseline numbers were collected using the following product versions and settings:

  • BEA WebLogic Server 8.1 GA product.
  • Sun JDK141_02 with the following Java output on a Solaris platform:

    java version "1.4.1_02-ea"

    Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-ea-b01)

    Java HotSpot(TM) Client VM (build 1.4.1_02-ea-b01, mixed mode)

  • BEA JRockit on the Windows platform.

    java version "1.4.1_02"

    Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02)

    BEA WebLogic JRockit(R) Virtual Machine (build 8.1-1.4.1_02-win32-CROSIS-20030317-1550, Native Threads, Generational Concurrent Garbage Collector)

  • Default WebLogic JVM configuration, except for the following:

    JVM configuration - Initial and maximum heap size set to 1G

    Thread count - Set to 50, the optimal value found.

    JDBC configuration:

    Used Oracle 9.2.0.2 Thin Driver

    JDBC Connection pool size set to 50 (initial and maximum), the optimal value found.

    JDBC StatementCacheSize set to 50.

    Cluster configuration - One Managed Server for each node with the Administration Server running on the first node.

 

Measured Configurations

The following configurations were measured:

  • WebLogic Server 8.1, Sun JDK141_02: 1-, 2-, 4- and 8-processor configuration on 750 MHz processor with 1 GB memory settings and one instance of WebLogic Server with BEA's best tuning.
  • WebLogic Server 8.1, Sun JDK141_02: 1-, 2-, 3- and 4-node configuration on 400 MHz processor with 1 GB memory settings and one instance of WebLogic Server per node with BEA's best tuning. The LoadRunner clients performed the load balancing.
  • WebLogic Server 8.1, JRockit version 141_02: 1-, 2-, 3- and 4-node configuration on 700 MHz processor with 1 GB memory settings and one instance of WebLogic Server per node with BEA's best tuning. The LoadRunner clients performed the load balancing.

 

Database Configurations

Oracle 9.2.0.2.0 was used on an eight-way 750 MHz E6800. To improve performance, the Oracle logs (8GB) were placed on a RAID array of four disks striped together and another RAID array of four disks striped for all the other database files.

Database configurations were as follows:

  • Host - Solaris 9
  • CPU - 8X 750 MHz UltraSparc III - Sun E6800
  • Memory - 8GB
  • Disk - 2 X 18GB + 4 x 18GB RAID Array
  • Software - Oracle9i Enterprise Edition Release 9.2.0.2.0

 

Client Configurations

Client configurations were as follows:

  • Host - Windows 2000 Advanced Server
  • CPU - 4X 700 MHz Poweredge 6400
  • Memory - 4 GB
  • Disk - 2 X 18GB
  • Software - LoadRunner 7.02

 

Network Configuration

A one gigabite (1 GB) network was used.

 

LoadRunner Configurations

LoadRunner 7.02 was used for client load generation on a 4X700 MHz Windows 2000 box with 4 GB of memory. No think time is used for the test. HTTP/HTTPs version 1.1 was used.

 

About Baseline Numbers

The baseline numbers produced by the benchmarks used in this study should not be used to compare WebLogic Server with other application servers or hardware running similar benchmarks.  The benchmark methodology and tuning used in this study are unique.

A number of benchmarks show how a well-designed application can perform on WebLogic Server. These benchmarks are available from BEA Systems. For more information, contact your BEA Systems sales representative.

 

Measured TPS for Light MedRec Application on UNIX

The measurements for the light MedRec application on UNIX were obtained using Solaris hardware and the HTTP protocol. Table 2-1 lists the number of clients in the first column, and hardware configuration with transactions per second in the remaining columns. For this application on UNIX, the designation for the configuration number is light medrec UNIX n where n is the configuration number (lmUn).

(TPS = Transactions Per Second)

 

Processor in MHz

Config #

1x750

lmU1

2x750

lmU2

4x750

lmU3

8x750

lmU4

4x400

1-node

lmU5

4x400

2-node

lmU6

4x400
3-node

lmU7

4x400
4-node

lmU8

Number of Clients TPS TPS TPS TPS TPS TPS TPS TPS
1 client 41.39 48.93 54.81 57.83 40.09
4 clients 43.96 76.16 122.54 148.54 88.26 136.91 149.94 161.85
10 clients 42.78 76.98 137.67 206.9 99.34 196.33 261.91
20 clients 43.54 78.05 142.51 214.26 100.11 207.36 308.54 395.5
40 clients 42.74 78.74 138.06 216.35 100.49 208.66 313.06 417.14
80 clients 43.01 78.48 138.84 215.24 99.72 206.09 310.43 418.71
100 clients 43.05 78.48 138.93 214.89 99.1 205.05 312.44 418.76
150 clients 310.19 415.82
200 clients 416.8
Max TPS 43.96 78.74 142.51 216.35 100.49 208.66 313.06 418.76
Appserver CPU Utilization for Max TPS 98% 97% 95% 91% 95.09% 95.58% 95.35% 95.22%
DB Server CPU Utilization for Max TPS <1% 1.30% 2.25% 3.91% 1.70% 3.64% 6.21% 9.70%
DB Server Disk Utilization for Max TPS 6% 12% 19% 28.24 13.94 27.79 40.58 53.25
X

Table 2-2 summarizes the TPS achieved for each processor type/configuration combination measured, and identifies the number of concurrent clients running to achieve the measured TPS result.

 

Processor Type, Configuration

Config #

Measured TPS

Number of Clients

Solaris 1x750 MHz lmU1 43.96 4
Solaris 2x750 MHz lmU2 78.74 40
Solaris 4x750 MHz lmU3 142.51 20
Solaris 8x750 MHz lmU4 216.35 40
Solaris 4x400 - 1 Node lmU5 100.49 40
Solaris 4x400 - 2 Node lmU6 208.66 40
Solaris 4x400 - 3 Node lmU7 313.06 40
Solaris 4x400 - 4 Node lmU8 418.76 100

 

Measured TPS for Heavy MedRec Application on UNIX

The measurements for the heavy MedRec application on UNIX were obtained using Solaris hardware and the HTTP protocol. Table 2-3 lists the number of clients in the first column, and hardware configuration with transactions per second in the remaining columns. For this application on UNIX, the designation for the configuration number is heavy medrec UNIX n (hmUn).

(TPS = Transactions Per Second)

 

Processor in MHz

Config #

4x750

hmU1

4x400

hmU2

Number of Clients

TPS

TPS

1 client 31.13 22.38
4 clients 70.25 52.9
10 clients 82.11 58.79
20 clients 79.42 58.96
40 clients 80.23 59.67
80 clients 80.33 59.89
100 clients 81.28 59.51
Max TPS 82.11 59.89
Appserver CPU Utilization for Max TPS 93.00% 94.06%
DB Server CPU Utilization for Max TPS 1.16% 0.89%
DB Server Disk Utilization for Max TPS 12.23% 9.22%

 

Measured TPS for Light MedRec Application on Windows 2000

The measurements for the light MedRec application on Windows 2000 were obtained using the HTTP protocol. Table 2-4 lists the number of concurrently running clients in the first column, and hardware configuration with transactions per second in the remaining columns. For this application on Windows 2000, the designation for the configuration number is light medrec Windows n (lmWn).

 

Processor

in MHz

Config #

Win2K

4x700

1-Node

lmW1

Win2K

4x700

2-Node

lmW2

Win2K

4x700

3-Node

lmW3

Win2K

4x700

3-Node

lmW3

Number of Clients

TPS

TPS

TPS

TPS

1 client 85.61
4 clients 200.7 274.92 287.13 313.91
10 clients 205.05 381 524.23
20 clients 202.61 378.53 578.9 759.9
40 clients 197.7 380.21 571.25 764.4
80 clients 194.64 375.03 573.41 745.75
100 clients 195.2 370.53 562.27 746.78
150 clients 560.64 744.11
200 clients 748.45
Max TPS 205.05 381 578.9 764.4
Appserver CPU Utilization for Max TPS 92.51% 92.42% 92.40% 92.82%
DB Server CPU Utilization for Max TPS 3.32% 7.63% 14.63 23.44%
DB Disk Server CPU Utilization for Max TPS 26.32% 44.63% 70.25% 88.98%

The following table summarizes the measured TPS achieved for each processor type/configuration combination measured, and identifies the number of concurrent clients running to achieve the measured TPS result.

 

Processor Type, Configuration

Config #

Measured TPS

Number of Clients

Windows 2000 4x700 MHz - 1 Node lmW1 205.05 10
Windows 2000 4x700 MHz - 2 Node lmW2 381 10
Windows 2000 4x700 MHz - 3 Node lmW3 578.9 20
Windows 2000 4x700 MHz - 4 Node lmW4 764.4 40

 

Measured TPS for Heavy MedRec Application on Windows 2000

The following are measurements for the heavy MedRec application on Windows 2000. All tests on all operating systems use the HTTPS (secure) protocol. The JVM used for heavy MedRec application is the Sun Microsystems JDK.

Table 2-6 lists the number of clients in the first column, and hardware configuration with transactions per second in the remaining columns. For this application on Windows 2000, the designation for the configuration number is heavy medrec { U | W } n (hmUn or mmWn).

 

Processor

in MHz

Config #

Win2K

4x700

hmW1

Number of Clients

TPS

1 client 41.62
4 clients 98.7
10 clients 97.81
20 clients 96.03
40 clients 95.49
80 clients 94.21
100 clients 94.36
Max TPS 98.7

 

Next Steps

After examining the characteristics and baseline results from sample applications, the next step is to compare your application to one or more of the baseline samples. Then proceed to Determining Hardware Capacity Requirements. These steps can assist you in generating capacity planning requirements for your application.

Skip navigation bar  Back to Top Previous Next