End-to-End Performance of a WebSphere Environment

End-to-End Performance of a WebSphereEnvironment Including Edge Components

��

ii End-to-End Performance of a WebSphere Environment Including Edge Components

Contents

End-to-End Performance of aWebSphere Environment Including EdgeComponents . . . . . . . . . . . . . 1Introduction to the WebSphere environmentperformance tests . . . . . . . . . . . . . 1Summary for the WebSphere environmentperformance tests . . . . . . . . . . . . . 2Hardware equipment and software environment forthe WebSphere environment performance tests . . . 4

Environment . . . . . . . . . . . . . 6Workload description . . . . . . . . . . 8

System setup for the WebSphere environmentperformance tests . . . . . . . . . . . . 11

WebSphere Application Server cluster setup . . 12Caching proxy server setup . . . . . . . . 14z/VM setting QUICKDSP . . . . . . . . 19z/VM Guest LAN type setup . . . . . . . 19

Results for the WebSphere environmentperformance tests . . . . . . . . . . . . 20

Single WebSphere Application Server . . . . . 20WebSphere Application Server cluster . . . . 32

Detailed set up examples for the WebSphereenvironment performance tests . . . . . . . . 34

WebSphere setup . . . . . . . . . . . 34Trade setup . . . . . . . . . . . . . 36Firewall setup . . . . . . . . . . . . 43WebSphere Load Balancer setup . . . . . . 46WebSphere Studio Workload Simulator script . . 48Web.xml . . . . . . . . . . . . . . 48Cachespec.xml . . . . . . . . . . . . 49ibmproxy.conf . . . . . . . . . . . . 58

Glossary for the WebSphere environmentperformance tests . . . . . . . . . . . . 59Other sources of information for the WebSphereenvironment performance tests . . . . . . . . 60Notices for the WebSphere environmentperformance tests . . . . . . . . . . . . 60

iii

iv End-to-End Performance of a WebSphere Environment Including Edge Components

End-to-End Performance of a WebSphere EnvironmentIncluding Edge Components

This paper describes the end-to-end performance of an WebSphere ApplicationServer 6.0.2 cluster environment including firewall systems, Edge components likeWebSphere Load Balancer and the caching proxy server, and the Web server.

Published January 2007

It uses a typical setup for application servers providing services into the Internet.The the systems with the application server are protected by implementing ademilitarized zpnme (DMZ), which suppresses direct access from the Internetcompletely and allowing only well controlled accesses to the servers via the proxy.The entire environment was set up with z/VM guests on z/VM 5.2.

Through the project, we gathered experience on how to analyze and tune a clusterenvironment on Linux on IBM System z using the Trade 6.0 (Trade) application.We also learned where some of the pitfalls can be found. We were trying to findthe best configuration to achieve the highest throughput.

To view or download the PDF version of this document, click on the followinglink:

End-to-End Performance of a WebSphere Environment Including EdgeComponents (about 2.2 MB)

Introduction to the WebSphere environment performance testsDetermining the parameters and settings used to tune WebSphere ApplicationServer when using a cluster environment including a firewall, WebSphere LoadBalancer, a caching proxy sever, and a Web server can be quite complex. Wewanted to perform a series of tests to create recommendations for this type ofenvironment.

Objectives

The goal of the End-to-End Performance of a WebSphere Environment on Linux onzSeries Including Edge Components project was to produce a best practices paperdescribing the end-to-end performance of a WebSphere® Application Server clusterenvironment including firewall systems, Edge components like WebSphere LoadBalancer and the caching proxy server, and the Web server.

The largest expansion was a four-node cluster. The network was split into threeareas with different security levels - the unsecure external zone, the demilitarizedzone (DMZ), and the trusted internal zone with the corresponding edgecomponents. This is a typical setup for application servers providing services intothe Internet. It protects the system with the application server and the data bysuppressing direct access from the Internet completely and allowing only wellcontrolled accesses via the proxy. The whole environment was setup with z/VM®

guests on z/VM 5.2. Through the project, we gathered experience on how toanalyze and tune a cluster environment on Linux® on IBM® System z® using theTrade 6.0 (Trade) application. We also learned where some of the pitfalls can befound. We were trying to find the best configuration to achieve the highest

1

throughput. The environment tested was a customer-like environment, not ahigh-end benchmark system. Our goal was to utilize a System z 8-way systemoffering a secure WebSphere Application Server environment using Edgecomponents. We did not try to produce the fastest transaction rates possible withWebSphere Application Server. Using more IFLs, we could have achieved betterscaling, but that was not our intent.

Executive summary

If the WebSphere Application Server runs CPU constrained, the throughput andresponse times are significantly limited and setup modifications can have anegative impact. Increasing the number of virtual CPUs for this system results inan improvement between 40% and 50% for the same scenario. This symptom is notobvious at all times. If the monitoring methodology creates averages over a certaintime span, it flattens the peaks.

Enabling caching, either Command or DistributedMap, is highly recommended aslong as data caching will not compromise data validity. We achieved the bestresults when using DistributedMap caching, which had a throughput 2.7 timeshigher than without caching. When enabling caching, take care to use anappropriate cache size for the WebSphere Application Server dynamic cache. Thesupport for using caching must be provided by the application owner.

For guest LANs the connection type HiperSockets™ with an appropriate MFS sizewould produce the highest throughput. Unfortunately, the edge component LoadBalancer does not support this connection type.

For guest LANs the connection type HiperSockets could be recommended, but anappropriate value for the Maximum File Size (MFS) size is required. Unfortunately,the edge component Load Balancer does not support this connection type.

A four-node cluster using no caching improves throughput by 70% compared to asingle WebSphere Application Server limited by the full utilization of the eightphysical CPUs of the LPAR. Using no caching creates a high CPU load on the DB2Universal Database™ server, so the utilization of the database server also needs tobe monitored for each cluster configuration.

The CPU cost for running under z/VM is shown by either the effort of the VMcontrol program itself, which was about 0.6%, and the effort for a specific guest,which was between 11% and 17%. In our tests we experienced no VM paging andthere was no XSTOR utilization. This was expected because we had no memoryovercommitment.

Summary for the WebSphere environment performance testsAfter performing performance tests on our WebSphere Application Serverenvironment, we compiled a summary of our results and recommendations.

Our test results and recommendations are Trade specific. Parameters useful in ourenvironment might be useful in other environments, but because caching benefitsand costs are highly dependent on application usage and system configuration,

2 End-to-End Performance of a WebSphere Environment Including Edge Components

you will need to determine what works best for your environment1. For ourdetailed test results information, refer to “Results for the WebSphere environmentperformance tests” on page 20.

The following are our summary results:v If the WebSphere Application Server runs CPU constrained, the throughput and

response times are significantly limited. If the monitoring methodology createsaverages over a certain time span, this scenario might not be obvious at all timesbecause it flattens the peaks. Because our two virtual CPUs were fully utilized,we also performed several tests with four virtual CPUs on the WebSphereApplication Server. We saw higher throughput with four virtual CPUs. Also, thelarger dynamic cache did not reduce the performance. See “Varying virtualCPUs on the WebSphere Application Server” on page 24 for details.

v For our tests, the UDB load was of particular interest for the ″No cache″ setting.In our single node tests, the UDB server was almost 70% utilized, so when westarted our cluster testing, we added a second CPU. For all other scenarios, thesingle CPU for UDB was sufficient.

v Enabling caching, either Command or DistributedMap, is highly recommendedas long as data caching will not compromise data validity. We achieved the bestresults when using DistributedMap caching. See “Varying Trade caching modes”on page 20 for details.

v Caching benefits and costs are highly dependent on application usage andsystem configuration.

v With a single WebSphere Application Server, the Trade caching option ofDistributedMap gave the best results. Improvement compared with the No cacheoption was a factor of 2.7. See “Varying Trade caching modes” on page 20 fordetails.

v To use caching with the caching proxy, it was necessary to install the latestfixlevel, 6.0.2-13 (efix update provided by lnx.6.0.2.12.nlv.390.nogskit.tar.gz fromftp://edgecust:[email protected]/edge/cp_without_gskit/6.0/) and to enable the socket pool on the caching proxy server. It is importantto ensure that the socket pool is not too small as well as to select a suitableconnections timeout setting. Be aware that because of the connection timeout,the sockets might be blocked longer than the user is connected. For ourworkload with 300 connected threads, setting the MaxSocketsPerServerparameter to 500 and the ServerConnTimeout parameter to 5 was suitable.

v We found that a WebSphere Application Server dynamic cache size of 10,000statements was best for all tests. When the WebSphere Application Server runsCPU constrained, a larger cache size reduced the throughput. See “VaryingWebSphere Application Server dynamic cache size” on page 27 for details.

v The response time was linearly related to the number of clients. Mostthroughput improvements, for a certain number of clients, also reduced theresponse time. See “Varying Trade clients” on page 29 for details.

v For the guest LAN type HiperSockets, a Maximum Frame Size (MFS) size of 24KB could be recommended. The MFS size is specific for this workload with

1. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY.WHILE EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION CONTAINEDIN THIS DOCUMENTATION, IT IS PROVIDED ″AS IS″ WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. INADDITION, THIS INFORMATION IS BASED ON IBM’S CURRENT PRODUCT PLANS AND STRATEGY, WHICH ARESUBJECT TO CHANGE BY IBM WITHOUT NOTICE. IBM SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUTOF THE USE OF, OR OTHERWISE RELATED TO, THIS DOCUMENTATION OR ANY OTHER DOCUMENTATION. NOTHINGCONTAINED IN THIS DOCUMENTATION IS INTENDED TO, NOR SHALL HAVE THE EFFECT OF, CREATING ANYWARRANTIES OR REPRESENTATIONS FROM IBM (OR ITS SUPPLIERS OR LICENSORS), OR ALTERING THE TERMS ANDCONDITIONS OF THE APPLICABLE LICENSE AGREEMENT GOVERNING THE USE OF IBM SOFTWARE.

End-to-End Performance of a WebSphere Environment Including Edge Components 3

small requests. The WebSphere Load Balancer does not support HiperSockets. Ifa load balancer is needed, the guest LAN type must be Queued Direct I/O(QDIO). See “Modifying the z/VM guest LAN type” on page 30 for details.

v If no caching is used, the environment could see a throughput improvement of70% using a four-node cluster (compared to a single WebSphere ApplicationServer). See “Varying WebSphere Application Server nodes without caching” onpage 32 for details.

v With no caching, a cluster of four WebSphere Application Servers, each with twovirtual CPUs, was able to saturate the eight physical CPUs in the LPAR.

v The CPU cost for the VM control program is shown by either the ratio of total tovirtual CPU or the percentage of total elapsed time that the processor wascharged to the system (control program time not attributed to specific users). Forthe total to virtual ratio we had an overhead from 11% to 17% for all CPUs. Thesystem cost was about 1.5% on CPU0 and about 0.5% on each of the other sevenCPUs.

v In our tests we experienced no VM paging and there was no XSTOR utilization.This was expected because we had no memory overcommitment.

Benefits of using z/VM

There are many benefits of using z/VM in a Linux on zSeries® environment. Thefollowing list shows how environments like ours could benefit from z/VM.v Using z/VM reduces administration effort

– Systems can be easily clonedv Isolated networks can be easily implemented without hardware and cablesv Easy administration of one physical systemv The Performance Toolkit for z/VM provides a single point to easily monitor all

serversv Using z/VM provides a very efficient use of the hardware

– Sharing physical resources leads to efficient hardware use.v The homogeneous structure of the systems lead to homogeneous usage of

hardware, which can be easily handled with less physical resources in a virtualenvironment, while a physical environment needs a component for each server.For example, one physical network card was sufficient to support our wholenetwork load.

v Using virtual CPUs allows consolidation of several low utilized systems on asmall number of CPUs with high utilization, which reduces cost and overhead.

v It is possible to use more virtual hardware than available physical hardware(over commitment).

v z/VM can increase speed for data transfers– Because virtual LANs are used, the latency associated with a physical

network is reduced and memory-to-memory data transfer rates could beachieved.

Hardware equipment and software environment for the WebSphereenvironment performance tests

To perform our WebSphere Application Server performance tests, we created acustomer-like environment. We configured the hardware, software, z/VM guests,the workload software, the caching proxy server, and the WebSphere LoadBalancer.


Server Hardware

Host On one LPAR on a 16-way IBM System z9®, type 2094-S18 (System z9-109,Model S18), equipped with:v 8 physical CPUs, dedicatedv 26 GB memoryv 5 GB expanded memoryv OSA Express 2 gigabit Ethernet card (OSA code level 0805)

z/VM guests setup:

MTU sizes:v QDIO - 1492v HiperSockets - 16,384

Table 1. Guest configuration

Host Name IP address OperatingSystem

Kernel Level # VirtualCPUs

Memory Function

LNX0008010.10.80.10192.168.30.10

SLES9 SP1 2.6.5-7.139-s390x 2 (4) 2 GB WebSphereApplicationServer

LNX0008110.10.80.200192.168.30.200

SLES9 SP2 2.6.5-7.191-s390x 1 (2) 2 GB DB2® UDB

LNX0008210.10.80.80192.168.30.80192.168.30.82(cluster address)

SLES9 SP1 2.6.5-7.139-s390(31-bit)

1 1.5 GB WebSphereLoad Balancer

LNX0008310.10.80.90192.168.40.90

SLES9 SP1 2.6.5-7.139-s390x 1 2 GB CachingProxy

LNX0008410.10.80.100192.168.30.100

SLES9 SP3 2.6.5-7.244-s390x 2 1 GB Web server

LNX0008610.10.80.11192.168.30.11

SLES9 SP1 2.6.5-7.139-s390x 2 2 GB WebSphereApplicationServer

LNX0008710.10.80.12192.168.30.12


LNX0008810.10.80.13192.168.30.13


LNX0009010.10.80.21192.168.30.21192.168.40.21

SLES9 SP3 2.6.5-7.244-s390x 1 0.5 GB Firewall 1

LNX0009110.10.80.22192.168.40.2210.10.60.22

SLES9 SP3 2.6.5-7.244-s390x 1 0.5 GB Firewall 2

Note: We did not have LNX00085 or LNX00089 hosts.

Network setup


v Fiber Gigabit Ethernet Interface connections to the clientsv Virtual guest LAN(s) on z/VM

Storage server setup

v Enterprise Storage Server® (ESS) 2105 800 with 2 Terabyte space– IBM 3390 model 3– DDMS - 15,000 RPMs

Client Hardware

1 x330 PC with 2 processors, 1.26 Ghz

Software

Table 2. Software Used

Product Version/Level

Apache HTTP Server 2.0.49

IBM DB2 Universal Database (DB2 UDB)Enterprise Server

8.2

iptables firewall Included with SUSE Linux

Red Hat Enterprise Linux RHEL 4 ES (Trade client)

SUSE Linux Enterprise Server v SLES9 SP1, 64-bit (required for WebSphereApplication Server, Caching Proxy, LoadBalancer)

v SLES9 SP2, 64-bit (required for DB2 UDB)

v SLES9 SP3, 64-bit (Web server, firewalls)

Trade 6.0.1

WebSphere Application Server EdgeComponents

v Caching proxy server

v Load balancer

6.0.2

WebSphere Application Server 6.0.2 (31 and 64-bit)

WebSphere Studio Workload Simulator iwl-0-03309L

z/VM 5.2

EnvironmentOur WebSphere Application Server environment consisted of an IBM System z andan IBM eServer™ xSeries® server and client.


The System z contained a z/VM LPAR with seven guests. The network was splitinto three parts:1. The xSeries and the System z systems were connected in the unsecure external

zone through an Extreme Mariner Switch. The xSeries system contained theWebSphere Studio Workload Simulator, which drove the Trade clients andgenerated the workload.

2. The DMZ contained one guest with the WebSphere Caching Proxy Serverprotected from the external zone with a less restrictive firewall (Firewall 2)running in a separate guest. It is implemented as a z/VM guest LAN.

3. The trusted internal zone, the second z/VM guest LAN, is protected withanother guest with a more restrictive firewall (Firewall 1) and contains oneguest for each of the following servers:v WebSphere Load Balancerv Apache Web Serverv WebSphere Application Serverv The DB2 UDB database server

The environment we used for our WebSphere Application Server clusters testing isshown in Figure 2 on page 8.

Figure 1. Single WebSphere Application Server test environment


This test environment was very similar to our single WebSphere Application Servertest environment (see Figure 1 on page 7). Added to this environment were threeadditional WebSphere nodes so that z/VM contained up to ten guests. The firstWebSphere node hosted the Deployment Manager, which was required to createthe cluster.

Workload descriptionThe Trade performance benchmark is a workload developed by IBM forcharacterizing performance of the WebSphere Application Server. The workloadconsists of an end-to-end Web application and a full set of primitives.

The applications are a collection of Java™ classes, Java Servlets, Java Server Pages,Web Services, and Enterprise Java Beans built to open J2EE APIs. Together theseprovide versatile and portable test cases designed to measure aspects of scalabilityand performance. Figure 3 shows an overview of the Trade J2EE components.

The new Trade benchmark (Trade 6) has been re-designed and developed to coverWebSphere’s significantly expanding programming model. This provides a morerealistic workload driving WebSphere’s implementation of J2EE 1.4 and Webservices including key WebSphere performance components and features.

Figure 2. Cluster test environment

Figure 3. Trade J2EE components


Trade’s new design spans J2EE 1.4 including the new EJB 2.1 componentarchitecture, Message Driven beans (MDBs), transactions (1-phase, 2-phase commit)and Web Services (SOAP, WSDL). Trade also highlights key WebSphereperformance components such as DynaCache, WebSphere Edge Server, and WebServices.

Trade is modeled after an online stock brokerage. The workload provides a set ofuser services such as login/logout, stock quotes, buy, sell, account details, and soon, through standards-based HTTP and Web services protocols.

Trade provides the following server implementations of the emulated Tradebrokerage services.v EJB - Database access uses EJB 2.1 technology to drive transactional trading

operations.v Direct - This mode uses database and messaging access through direct JDBC and

JMS code

Type 4 JDBC connectors were used with EJB containers. See Figure 3 on page 8 fordetails.

EJB 2.1

Trade 6 continues to use the following features of EJB 2.0 and leverages EJB 2.1features such as enhanced Enterprise JavaBeans™ Query Language (EJBQL),enterprise Web services and messaging destinations.v Container-Managed Relationships – One-to-one, one-to-many, and many-to-many

object to relational data managed by the EJB container and defined by anabstract persistence schema. This feature provides an extended, real-world datamodel with foreign key relationships, cascaded updates and deletes, and so on.

v EJBQL – Standardized, portable query language for EJB finder and selectmethods with container-managed persistence.

v Local and Remote Interfaces - Optimized local interfaces providing pass-byreference objects and reduced security overhead.

WebSphere Application Server provides significant features to optimize theperformance of EJB 2.1 workloads. Trade uses access intent optimization to ensuredata integrity while supporting the highest performing and scalableimplementation. Using access intent optimizations, entity bean run-time data accesscharacteristics can be configured to improve database access efficiency whichincludes access type, concurrency control, read-ahead, collection scope, and soforth.

The J2EE programming model provides managed, object-based EJB components.The EJB container provides declarative services for these components such aspersistence, transactions, and security. The J2EE programming model also supportslow-level APIs such as JDBC and JMS. These APIs provide direct access to resourcemanagers such as database and message servers. Trade provides a Directimplementation of the server-side trading services using direct JDBC. Thisimplementation provides a comparison point to container-managed services thatdetails the performance overhead and opportunity associated with the EJBcontainer implementation in WebSphere Application Server.

All the measurements done in this study used EJB.


Trade provides two order processing modes: asynchronous and synchronous. Theorder processing mode determines the mode for completing stock purchase andsell operations. Asynchronous mode uses MDB and JMS to queue the order to aTradeBroker agent to complete the order. Asychronous_2-Phase performs atwo-phase commit over the EJB database and messaging transactions. Synchronousmode, on the other hand, completes the order immediately.

All the measurements done in this study used synchronous order processingmode.

Trade provides the following access modes to the server-side brokerage services.v Standard - Servlets access the Trade enterprise beans through the standard RMI

protocolv WebServices - Servlets access Trade services through the Web services

implementation in WebSphere Application Server. Each trading service isavailable as a standard Web service through the SOAP Remote Procedure Call(RPC) protocol. Because Trade is wrapped to provide SOAP services, each Tradeoperation (login, quote, buy, and so on) is available as a SOAP service.

All the measurements done in this study used the Standard access mode.

For all measurements in this study, the Trade database was populated with 500users (uid:0 - uid:499) and 1000 quotes (s:0 – s:999).

Trade can run with any of the following WebSphere Application Server cachingmodes.v No cache - No caching is used.v Command caching - This caching feature was added to WebSphere Application

Server V5.0 for storing command beans in the dynamic cache service. Supportfor this feature was added in Trade 3 and carried over to Trade 6.

v DistributedMap - This feature is new in WebSphere Application Server V6.0,providing a general API for storing objects in the dynamic cache service.

For our tests, all of the above caching modes were examined.

In our environment, Trade requests followed a particular path. When a Trade clientissued a request, the request was routed through the first firewall (Firewall 2 inFigure 1 on page 7) to the caching proxy server, which was allowed to forward therequest through the back firewall (Firewall 1 in Figure 1 on page 7) to theWebSphere Load Balancer. The WebSphere Load Balancer then forwarded therequest to the Web server, which in turn, forwarded it to WebSphere ApplicationServer. Communication between the WebSphere Load Balancer, the Web server, theWebSphere Application Server servers, and the database occurred over the internalz/VM guest LAN (Guest LAN 2 in Figure 1 on page 7). Responses back to theclient followed the same reverse path.

Detailed information on the Trade workload can be found in Appendix A of theIBM Redbook Using WebSphere Extended Deployment V6.0 To Build an On DemandProduction Environment found at:

http://www.redbooks.ibm.com/abstracts/sg247153.html

Information on how Trade works with WebSphere Application Server can be foundat:http://www.ibm.com/software/webservers/appserv/was/performance.html


WebSphere Studio Workload SimulatorThe Trade workload was driven by the WebSphere Studio Workload Simulator andthe WebSphere Studio Workload Simulator script provided with the Tradedistribution.

One of the parameters that is specifiable for WebSphere Studio Workload simulatoris the number of clients that will be executing the script. The WebSphere StudioWorkload Simulator configuration that was used to execute all the measurementsin this study specified 300 worker threads. Simulated clients are executed byworker threads. Increasing the number of clients increases the transaction rate orload on the Trade application executing on the WebSphere Application Server. BothCommand caching and DistributedMap caching were used.

Caching proxy serverThe caching proxy server intercepts requests from the client, retrieves the requestedinformation from the content-hosting machines, and delivers that information backto the client.

For details on our caching proxy server setup, see “Caching proxy server setup” onpage 14 and “Detailed set up examples for the WebSphere environmentperformance tests” on page 34.

WebSphere Load BalancerThe dispatcher component of WebSphere Load Balancer was used for ourWebSphere Application Server environment test runs.

WebSphere Load Balancer consists of the following five components that can beused separately or together:v Dispatcherv Content based routing (CBS) for HTTP and HTTPSv Site Selectorv Cisco CSS Controllerv Nortel Alteon Controller

For the environment in this study, only the WebSphere Load Balancer dispatchercomponent was used. The dispatcher component distributes the load it receives toservers contained in a cluster (a set of servers that run the same application andcan provide the same content to its clients). This mechanism is also known as IPspraying. When the environment contained only one Web server, no IP sprayingoccurred. See “WebSphere Load Balancer setup” on page 46 for the configurationfile used for the WebSphere Load Balancer.

System setup for the WebSphere environment performance testsTo emulate a customer-like environment we set up and configured our z/VMLPARs and guests. We also created a WebSphere Application Server cluster, setupthe caching proxy server, enabled quick dispatch, and setup the z/VM guest LANtype.

General information for single WebSphere Application Serversetup

Figure 1 on page 7 shows the system topology that was used to gather the resultsfor our single WebSphere Application Server tests.


The table below lists the specific configuration details for the z/VM LPAR and theguests defined for the tests.

Table 3. LPAR and guest configuration details

Function Type CPUs Memory Network IP address

z/VM LPAR 8 26 GB Physical LAN 9.12.22.92

WebSphereApplication

Server

guest 2 (4) 2 GBGuest LAN 192.168.30.10

10.10.80.10

DB2 UDB guest 1 (2) 2 GBGuest LAN 192.168.30.200

10.10.80.200

WebSphereLoad Balancer

guest 1 1536 MBGuest LAN 192.168.30.80

192.168.30.8210.10.80.80

Web server guest 2 1 GBGuest LAN 192.168.30.100

10.10.80.100

Cachingproxy server

guest 1 2 GBGuest LAN 192.168.40.90

10.10.80.90

Firewall 1 guest 1 512 MBGuest LANGuest LAN

192.168.40.2110.10.30.2110.10.80.21

Firewall 2 guest 1 512 MBGuest LAN

Physical LAN192.168.40.22

10.10.60.22

Client xSeries 2 4 GB Physical LAN10.10.60.147

For all configurations, the netmask was 255.255.255.0.

See “Detailed set up examples for the WebSphere environment performance tests”on page 34 for the configuration files used for the environment.

See the following RedBook for general instructions on installing and configuringthe various components in the topology: WebSphere Application Server V6 Scalabilityand Performance Handbook, which can be found at:http://www.redbooks.ibm.com/redbooks/pdfs/sg246392.pdf

WebSphere Application Server cluster setupIn order to build a WebSphere cluster, it was necessary to install WebSphereApplication Server Network Deployment V6.02.

This software package was installed on four guests, the number of nodes thatwould be included in the final cluster. One guest was configured as both anapplication server and the Deployment Manager. The Deployment Manager profilewas defined first and then the four application server profiles were defined, one oneach guest. The application server profiles were federated into the defined clusterduring their definition. Next, the Trade application was installed using the Trade


supplied JACL scripts with the cluster option using the wsadmin.sh scriptassociated with the deployment manager. The Trade JACL script handles the finalconfiguration of the federated nodes into a cluster.

The WebSphere Load Balancer must be configured so that it recognizes theWebSphere Application Server cluster. In the test environment, this is the IPaddress 192.168.30.82.

After the cluster was created, a new WebSphere plugin.xml file was created fromthe Deployment Manager’s administration console. The plugin.xml file was thencopied to the Web server guest and the httpd.conf file was changed to point to thenew cluster plugin.xml file.

In order to run with the Trade caching options in a WebSphere cluster, it isnecessary to create a replication domain that will handle the management of thecached objects between the members of the cluster. This was done from theDeployment Manager’s Administration console, Environment > ReplicationDomains > New.

The number of replicas was set to the entire domain and the policy was set topush-pull.

Table 4 details the additional guests and components used for these tests. For atwo-node cluster, one additional z/VM guest was added to the environment andfor a four-node cluster, two additional z/VM guests were added.

Table 4. Test environment

z/VM guests Memory size CPUs

Firewall2 512 MB 1

Proxy server 2 GB 1

Firewall1 512 MB 1

WebSphere Load Balancer 1536 MB 1

Web server 1 GB 2

WebSphere ApplicationServer (1 - LNX00080)

2 GB 2 (4)


2 GB 2 (4)


2 GB 2


2 GB 2

DB2 UDB 2 GB 1 (2)

For our two-node cluster environment, we used WebSphere Application Serverguests 1 (LNX00080) and 2 (LNX00086). For all our cluster tests, all virtual CPUswere provided by one z/VM in one LPAR with eight physical CPUs. This setupcreated a significant virtual CPU overcommitment with our one-node system usingnine virtual CPUs and our four-node system using 16 CPUs (see Table 4 for moredetails).


Caching proxy server setupThe caching proxy server stores cacheable content in a local cache before deliveringit to the requester. You can configure the caching proxy server to handle protocolssuch as HTTP, FTP, and Gopher.

It does not store all content, only specific cacheable content that meets its rules.Examples of cacheable content include static Web pages and whole dynamic Webpages. Caching enables the caching proxy server to satisfy subsequent requests forthe same content by delivering it directly from the local cache, which is muchquicker than retrieving it again from the content host. Our caching proxy serverwas configured to use memory.

There are two basic types of caching content:v Static content

Static content does not change over long periods of time. The content type canbe HTML, JSP rendering less dynamic data, GIF, JPG, or others. Static content ischaracterized by content that is not generated on the fly and has predictableexpiration values. Such content typically resides on the file system of the Webserver or application server and is served unchanged to the client. To a largeextent this content can be declared to be cacheable. This type of content istypically cached at a caching proxy. See Figure 4 on page 15.

v Dynamic contentDynamic content includes frequently updated content (such as exchange rates),as well as personalized and customized content. Although it is changing content,at the same time it must be stable over a long enough period for meaningfulreuse to occur. However, if some content is very frequently accessed, such asrequests for pricing information of a popular stock, even a short period ofstability may be long enough to benefit from caching. This type of content istypically cached in the dynamic cache services of the application server or theESI cache of the Web server plug-in (note that in our tests we did not use ESIcaching). See Figure 4 on page 15.


Because the Trade application does not contain content that meets the static contentcriteria (Trade has only one page, the login page, that meets the requirements forexternal caching), the caching proxy server did not cache any content during ourtests (WebSphere Application Server V6 Scalability and Performance Handbook). Trade’sdynamic content was cached in the application server’s dynamic cache servers fortests in which Trade caching was enabled.

The following screen shots (Figure 5 on page 16) from the caching proxyadministrator panels show the activity statistics (top screen shot) and cachingstatistics (bottom screen shot) for the caching proxy during one of the Trade runs.

Figure 4. Caching content types


These screen shots show that no Trade application pages were being cached at thecaching proxy. The activity statistics show that there are a high number of requestswhile the cache statistics show no cache hits.

The caching proxy server can also be configured as a reverse or forward proxyserver.

The Edge Server caching proxy functions as a reverse proxy when it is locatedbetween a client browser on the Internet and Web servers that are located behind afirewall. In this role, the caching proxy intercepts user requests arriving from theInternet, forwards them to the appropriate host Web server, caches the returneddata, and delivers that data to the client user across the Internet.

For more information on the caching proxy, see the caching proxy manuals at:

Figure 5. Caching proxy activity and cache statistics


http://www.ibm.com/software/webservers/appserv/doc/v602/ec/infocenter/index.html

Dynamic caching with Trade and WebSphereThe dynamic cache service improves performance by caching the output ofservlets, commands, and Java Server Pages (JSP) files.

By caching the response from servlets, Web services, JSPs, and WebSphereApplication Server commands, the application server does not have to perform thesame computations and back-end queries multiple times. The WebSphereApplication Server consolidates several caching activities, including servlets, Webservices, and WebSphere commands into one service called the dynamic cache.These caching activities work together to improve application performance andshare many configuration parameters, which are set in an application server’sdynamic cache service. The dynamic cache works within an application server JavaVirtual Machine (JVM) intercepting calls to cacheable objects, for example, througha servlet’s service() method or a command’s execute() method, and either stores theobject’s output to or serves the object’s content from the dynamic cache. BecauseJ2EE applications likely have high read/write ratios and can tolerate small degreesof latency, the dynamic cache can create an opportunity for significant gains inserver response time, throughput, and scalability to make the data current.However, the possible use of dynamic caching technology should be reviewed withapplication developers and owners so they will design and program to ensure datavalidity is maintained should WebSphere data caching be activated.

A cache hit is generally served in a fraction of the time of a non-cached request.Significant performance gains are generally achieved with Trade when dynamiccaching technology is used.

The only parameter that can be set in the WebSphere Application Server for thedynamic cache service is the size of the cache, which is expressed as the maximumnumber of entries that the cache can hold. This value is set using the WebSphereApplication Server administration console under application servers >server_name > web container services > dynamic cache service. The actualcaching service mode is set by each application individually.

WebSphere Application Server V6.0 provides two interfaces,DistributedObjectCache and DistributedMap, by which J2EE applications can cacheand share Java objects by storing a reference to the object in the cache. Theseinterfaces expand on the command bean and servlet fragment caching capabilitiesalready provided in previous versions of WebSphere Application Server. Bydefault, the caching capabilities within Trade are disabled. However, the cachingtype can be modified to use either the DistributedMap interface or command beancaching (Command caching) interface.

Trade provides settings for multiple caching modes. By modifying the setting inthe web.xml file, which can be found in /opt/IBM/WebSphere/AppServer/profiles/default/installedApps/<WebSphere node>/trade.ear/tradeWeb.war/WEB-INF, you indicate the dynamic caching technology to be used by Trade. By default,data caching is disabled (set to No caching) in Trade. The Trade supported cachingmodes are:v No cache - No caching is used.v Command caching - This caching feature was added to WebSphere Application

Server V5.0 for storing command beans in the dynamic cache service. Supportfor this feature was added in Trade 3 and carried over to Trade 6.


v DistributedMap - This feature is new in WebSphere Application Server V6.0,providing a general API for storing objects in the dynamic cache service.

For the measurements we took in this study, we used the three caching modes (Nocache, Command Caching, DistributedMap caching). See “Web.xml” on page 48 forthe section of the web.xml file that is modified for dynamic caching.

Dynamic caching requires that the application supply a cachspec.xml file (found in/opt/IBM/WebSphere/AppServer/profiles/default/installedApps/<WebSpherenode>/trade.ear/tradeWeb.war/WEB-INF) that defines the caching policies for theapplication. “Cachespec.xml” on page 49 contains the file that was used for all ourmeasurements.

MaxSocketsPerServer and ServerConnTimeout parametersThe MaxSocketPerServer directive is used to set the maximum number of opensocket connections, that are maintained, to any one origin server and theServerConnTimeout directive is used to limit the time allowed without networkactivity before canceling a socket connection.

Setting the ServerConnPool directive to ON in the caching proxy configuration filewill reduce the number of new connections created to the back-end server bycausing the caching proxy to reuse existing socket connections.

The caching proxy server is configured at system initialization by the values set inthe ibmproxy.conf file located in /etc. The following configuration statements inthe ibmproxy.conf file were significant for the measurements in this study (see“ibmproxy.conf” on page 58 for details on these areas of the ibmproxy.conf file):v Proxy /* http://192.168.30.82/* :80

This directive passes http protocol requests to a remote server (the WebSphereLoad Balancer cluster).

v ReversePass http://192.168.30.82/* http://192.168.40.90/*The ReversePass mapping directive examines the server response stream todetect requests that are rewritten as a result of automatic redirection. Typically,when a server returns an http code in the 3xx class (for example, 301 for ″movedpermanently″, or 303 for ″see other″), the server sends a message with the replythat instructs the requesting client to direct future requests to the correct URLand IP address. In the case of a reverse proxy setup, a redirection message fromthe origin server can cause client browsers to bypass the proxy server forsubsequent requests. To avoid having clients directly contact the origin server,we used the ReversePass directive to intercept requests that were madespecifically to the origin server. The use of this directive insured that all trafficfrom the client WebSphere Studio Workload Simulator driver was routedthrough the caching proxy server.

v MaxSocketsPerServer 500This directive is used to set the maximum number of open sockets to maintainfor any one origin server. Use this directive only if the ServerConnPool directiveis set to ON. The value of 500 gave the best throughput in our environment.

v ServerConnTimeout 5 secondsThis directive was used to limit the time allowed without network activitybefore canceling the connection. Use this directive only if the ServerConnPooldirective is set to ON. The value of 5 seconds gave the best throughput in ourenvironment.


z/VM setting QUICKDSPWhen the quick dispatch option is assigned to a virtual machine, that virtualmachine is added to the dispatch list immediately, whenever it has work to do,without waiting in the eligible list.

Events can occur that cause the quick dispatch virtual machine to enter thedormant list. However, as soon as the quick dispatch virtual machine becomesdispatchable again, it enters the dispatch list without waiting in the eligible list.

Because the quick dispatch virtual machines are always in the set of virtualmachines being dispatched when not in the dormant list, they avoid waiting in theeligible list with other machines that can spend time waiting in the eligible list.

The SET QUICKDSP command or the QUICKDSP operand of the OPTIONdirectory statement assigns the QUICKDSP operand to a virtual machine.

All measurements were done with the QUICKDSP option on for all guests.

z/VM Guest LAN type setupThe z/VM guest LAN feature provides support for network connection of guestmachines. Guest LANs can be used for TCP/IP communication between guests orbetween guests and a z/VM TCP/IP service machine.

A VM guest LAN can only support connections to virtual machines on the sameVM system. The z/VM configuration used in this study defined two guest LANs,one for the DMZ and the other for the internal zone. A guest LAN can eithersimulate a QDIO LAN or a HiperSockets LAN. For HiperSockets, the MFSspecified on the guest LAN definition is also important. The MFS can be definedfor the guest LAN as 16 KB, 24 KB, 40 KB, or 64 KB.

The following z/VM commands were used to define the guest LANs:

for HiperSockets:'cp def lan vlan1h owner system type hiper mfs xxk''cp def lan vlan2h owner system type hiper mfs xxk'

for QDIO'cp def lan vlan1 owner system type qdio''cp def lan vlan2 owner system type qdio'

The guest LANs included in our tests were intended to have no access to an OSAcard because this was an isolated network and the only access from the externalLAN to the WebSphere Application Server was through the DMZ.

Because the WebSphere Load Balancer does not support a HiperSockets connectednetwork, we bypassed the WebSphere Load Balancer for these measurements. TheProxy and ReversePass statements in the ibmproxy.conf file were changed, asshown below, to point to the web server.Proxy /* http://192.168.30.100/* :80

ReversePass http://192.168.30.100/* http://192.168.40.90


Results for the WebSphere environment performance testsAfter performing our WebSphere Application Server environment performancetests, we charted our test results, interpreted the results, and createdrecommendations.

Throughout all our tests the CPU utilization from the LPAR was measured withthe Performance Toolkit for z/VM. The average values were calculated manuallyover the correct interval.

We ran several tests in two main settings, ″Single WebSphere Application Server″and ″WebSphere Application Server Cluster.″ The tests we performed in eachsetting included:v “Single WebSphere Application Server”

– “Varying Trade caching modes”– “Varying virtual CPUs on the WebSphere Application Server” on page 24– “Varying WebSphere Application Server dynamic cache size” on page 27– “Varying Trade clients” on page 29– “Modifying the z/VM guest LAN type” on page 30

v “WebSphere Application Server cluster” on page 32– “Varying WebSphere Application Server nodes without caching” on page 32

Single WebSphere Application ServerThe tests we ran in the single WebSphere Application Server setting allowed us tomeasure throughput differences when using different settings in the Tradeapplication, WebSphere caching, DB2 UDB, networking (caching proxy server,LAN), and using the 64-bit version of WebSphere.

Trade

Caching can be handled in one of three ways in the Trade application. The optionsare No cache, Command caching, and DistributedMap caching. We ran tests witheach of these options. We also varied the number of clients to see how the systemreacted when the load is increased.

WebSphere

WebSphere also provides settings that can affect your throughput. You can set yourdynamic cache size and vary the number of virtual CPUs for this server. We rantests adjusting these figures.

Network settings

We also looked at ways to improve throughput via the network settings at thecaching proxy server (size of the socket pool, length of time outs) and the z/VMguest LAN type (QDIO and HiperSockets).

See Table 3 on page 12 for our system setup for our single WebSphere ApplicationServer measurements.

Varying Trade caching modesTo study the impact of the different Trade caching modes on throughput, we ranseveral tests using the available Trade caching modes (No caching, Command


caching, and DistributedMap caching). For these tests, we used the singleWebSphere Application Server setup (see Table 3 on page 12).

Figure 6 shows the impact of the different Trade cache modes on throughput andwith two and four virtual CPUs. The throughput maximum was reached withdifferent numbers of clients, therefore the response time is not shown here becauseit is dependent on the number of clients. See “Varying Trade clients” on page 29for details.

Observations

Enabling caching improves the throughput beyond a factor of 2. The best resultwas with DistributedMap caching. The throughput was nearly 2.7 times higherthan without caching. The impact of the virtual CPUs is discussed in “Varyingvirtual CPUs on the WebSphere Application Server” on page 24.

To understand the impact of caching on our environment better, a deeper analysisof the system behavior where the WebSphere Application Server had two CPUswas done. We considered the following caching modes:v No Cachev Command cachingv DistributedMap caching

The first analysis of these tests is shown in CPU utilization in Figure 7 on page 22

Figure 6. Varying Trade caching modes - transaction throughput


Observations

The CPU utilization on the system is consistent with the throughput increase,except for the WebSphere Application Server, which is fully utilized in allscenarios. The UDB server had the highest CPU load when the caching was set to″No cache″.

The chart shows that caching on the WebSphere Application Server reduces theCPU load on the UDB server. However, we see an increase of the CPU utilizationbetween Command and DistributedMap caching, which is because of the increasedoverall throughput.

The total network I/O (received and sent from all interfaces involved) is shown inFigure 8 on page 23.

Figure 7. Trade caching modes - CPU utilization


Observations

Figure 8 shows that the caching proxy itself does not cache any requests and thenetwork throughput scales very close to the Trade throughput. The WebSphereLoad Balancer shows a very low load, because it was only involved when a newconnection was established. The throughput on the WebSphere Application Servershows that the only caching happens between the Web server and the WebSphereApplication Server and there was good caching efficiency. While the Tradethroughput increased up to a factor of 2.7, the network throughput increased only70%. The network throughput on the UDB server was also significantly reduced,but it increased with DistributedMap caching as shown with the higher Tradethroughput.

Disk I/O appeared only for writes because there was almost no read activity onthe disks during the measurement window. The only system which was expectedto have read activity was the database. However, the database buffers were largeenough that the data could be held there so there was no need to read it from disk.The write activity on the DB2 UDB server was caused by updates and log writes.

Conclusions

Enabling caching, either Command or DistributedMap, is highly recommended aslong as data caching will not compromise data validity. All further measurementswe ran were performed with DistributedMap caching. With no caching, there is ahigh CPU load on the DB2 UDB server.

Figure 8. Varying Trade cache modes - total network I/O per server


Related information

WebSphere environment performance tests - hardware equipment and softwareTo perform our WebSphere Application Server performance tests, we created acustomer-like environment. We configured the hardware, software, z/VM guests,the workload software, the caching proxy server, and the WebSphere LoadBalancer.WebSphere environment performance tests - system setupTo emulate a customer-like environment we set up and configured our z/VMLPARs and guests. We also created a WebSphere Application Server cluster, setupthe caching proxy server, enabled quick dispatch, and setup the z/VM guest LANtype.WebSphere environment performance tests - detailed set up examplesThe detailed setup we performed to setup WebSphere Application Sever, Trade,and WebSphere Load Balancer, as well as the scripts we used, are provided here.WebSphere environment performance tests - glossaryTerms used in the End-to-End Performance of a WebSphere Environment on Linuxon zSeries Including Edge Components paper are defined here.WebSphere environment performance tests - other sources of informationAdditional resources to provide information on the products, hardware, andsoftware discussed in this paper can be found in various books and at various Websites.

Varying virtual CPUs on the WebSphere Application ServerThis test takes a closer look at the impact of the number of virtual CPUs on theWebSphere Application Server.

As shown in “Varying Trade caching modes” on page 20, the WebSphereApplication Server on two virtual CPUs runs at 100% utilized for all cachingmodes. Therefore, we increased the number of virtual CPUs on the WebSphereApplication Server, which resulted in throughput improvements up to 48%.

Table 5. Improvements of using four virtual CPUs on the WebSphere Application Server(percentage)

Cache Mode Percentage Improvement

No cache 37%

Command caching 48%

DistributedMap caching 39%


Response time

Observations

Figure 9 shows the CPU utilization of the LPAR for the DistributedMap cachemode when increasing the number of virtual CPUs on the WebSphere ApplicationServer from two to four. The throughput increased by 40%, while the responsetime decreased by 30% to below 20 ms, which is a very good value.

CPU Utilization of the LPAR

Observations

Figure 9. Varying virtual CPUs on WebSphere Application Server with DistributedMap cachemode (transaction throughput and response time)

Figure 10. Varying virtual CPUs on WebSphere Application Server with DistributedMapcaching (LPAR system load - eight physical CPUs)


Figure 10 on page 25 shows the CPU utilization of the LPAR (eight physical CPUs)from the Performance Toolkit for z/VM from a phase during the measurement.The utilization of the eight physical CPUs from the LPAR increased from 55% to79% by adding two more virtual CPUs to the WebSphere Application Server.

Observations

Figure 11 shows the physical CPU consumption per throughput of 1,000 pages persecond. The higher throughput with four virtual CPUs on the WebSphereApplication Server adds very small additional virtual CPU overhead to the cost of4.5%.

Conclusions

It is important to assign enough CPUs to the WebSphere Application Server, whichcould easily be done under z/VM, because these are only virtual CPUs. In ourcase, the additional CPUs for the WebSphere Application Server resulted insignificantly higher throughput and better response times. The physical CPUutilization scales very close with the throughput with only a small overhead of4.5%. The LPAR load of 79% indicates that it should be possible to increase thethroughput further by using a cluster.

Be aware that this scenario (WebSphere Application Server runs CPU constrained)might not be obvious because of the methodology of the monitoring software. Themeasured values are averaged over a particular time space, so the fluctuations ofthe load are mostly flattened out. The reported values might not indicate that thereis a bottleneck so it is very important to monitor the CPU utilization on a verygranular level, if this needs to be identified.

Figure 11. Varying CPUs on Websphere Application Server with DistributedMap caching


Related information


Varying WebSphere Application Server dynamic cache sizeTo study the impact of the size of the dynamic cache size from WebSphereApplication Server on throughput, we ran several tests varying the cache size from2,000 to 20,000 statements.

The dynamic cache service is only applicable when Trade is configured to useeither Command caching or DistributedMap cache. DistributedMap caching wasselected because previous tests had shown this type of caching to produce thehighest throughput.

By default, the dynamic cache size is set to 2,000 statements. Tests were then run at2,000, 6,000, 10,000, and 20,000 statements. The WebSphere Application Serverdynamic cache monitor application was used to check cache usage and it wasobserved that at 10,000 statements the cache was never full.

Figure 12 on page 28 shows the impact of the size of the dynamic cache fromWebSphere Application Server had on throughput. In the tests we ran, we variedthe dynamic cache size from 2,000 to 20,000 statements.


Observations

With two CPUs the throughput increases linearly as the dynamic cache size isincreased up to 10,000 statements, at which point the throughput hits a peak. An8% decrease in throughput was seen at 20,000 statements. With four CPUs thethroughput does not degrade. The WebSphere cache monitoring applet was usedto examine dynamic cache usage. It showed that the dynamic cache nevercontained more than 8,600 statements at the same time.

Conclusions

Based on these tests, we used a dynamic cache size of 10,000 statements for allfurther test runs. The decrease in performance with two CPUs and 20,000statements is related to the full CPU utilization of the WebSphere ApplicationServer. The throughput stays stable when the WebSphere Application Server getsmore virtual CPUs. This shows that when the WebSphere Application Server runsCPU constrained the throughput is not only limited, but modifications in theenvironment might lead to a degradation.

Figure 12. Varying WebSphere Application Server dynamic cache size - transactionthroughput


Related information


Varying Trade clientsTo study the impact of the number of clients on performance, we ran several testswhere we modified the number of clients for the Command cache andDistributedMap cache modes.

Figure 13 shows the impact the number clients had on performance. We varied thenumber of clients for the cache modes Command caching and DistributedMapcaching.

Observations

Figure 13. Varying Trade clients with command caching


Figure 13 on page 29 shows the impact of varying clients when using Commandcaching. Between 15 and 40 clients, the throughput amount fluctuates around theaverage about plus or minus 1%. Of particular interest is the strong linearrelationship of the response times.

Using DistributedMap caching shows the same behavior. Here, throughput amountfluctuates also around the average about plus or minus 1%. The response timeshows the same strong linear relationship, but at lower values (80 - 90%) than forCommand caching (see Figure 13 on page 29).

Conclusions

If the number of clients exceeds a certain maximum, the throughput decreases veryslightly, but the response time scales linearly with the number of clients. When themaximum is reached, throughput is no longer improved by adding clients.Therefore, when observing response time, it is important to look at values fromruns with the same number of clients.Related information


Modifying the z/VM guest LAN typeTo study the impact of the z/VM guest LAN type, we ran several testsinterchanging HiperSockets and QDIO and varying the MFS size parameter.

See “z/VM Guest LAN type setup” on page 19 for details on our setup for thesetests.

Because the WebSphere Load Balancer does not support a HiperSockets connectednetwork, we bypassed the WebSphere Load Balancer for these measurements.

Figure 14 on page 31 shows the impact of switching the z/VM guest LAN typefrom QDIO to HiperSockets and varying the MFS size parameter.


Observations

Switching the guest LAN type to HiperSockets increased the throughput by 4%,which is further improved when enlarging the MFS size to 24 KB. The finalincrease, compared to QDIO is 7%. It is also interesting that the response time isreduced by 3 ms. One explanation is that software emulation of guest LAN typeHiperSockets has a shorter path length than guest LAN type QDIO.

Conclusions

Generally, from a performance view point, the usage of the guest LAN typeHiperSockets instead of QDIO could be recommended for this type of workload.Unfortunately, the missing support for the WebSphere Load Balancer forces the useof QDIO if the WebSphere Load Balancer is required.

Figure 14. Varying network types and MFS size


Related information


WebSphere Application Server clusterThe objective of these tests was to show the impact of a WebSphere ApplicationServer cluster on performance.

Because of the available physical CPU capacities (no previous tests were able tosaturate eight physical CPUs), the expectation was that this should further improvethe throughput. See “WebSphere Application Server cluster setup” on page 12 fordetails on our setup.

Varying WebSphere Application Server nodes without cachingTo determine the impact of using a WebSphere Application Server cluster andvarying the nodes without using caching, we ran several tests varying the nodesused in the cluster. The Trade database was defined on the DB2 UDB z/VM guestand measurements were done varying the number of clients and setting the Tradecaching mode to ″No caching.″


Observations

Figure 15 shows the behavior of a WebSphere Application Server cluster with one,two, and four WebSphere Application Server nodes. With two WebSphereApplication Server nodes, the throughput increased significantly and drove thevirtual CPU on the UDB server to its limit. Adding a second virtual CPU increasedthe throughput further and allowed additional clients to be served. With fourWebSphere Application Server nodes we reached a throughput improvement of70%.

Figure 15. Varying WebSphere Application Server nodes without caching (transactionthroughput)

Figure 16. Varying WebSphere Application Server nodes without caching (LPAR system load- eight physical CPUs)


Observations

Figure 16 on page 33 also shows that the virtual CPU utilization of the LPARincreased even further, up to 100%, meaning that the system was fully utilized.

Conclusions

If no caching is used, the environment could see a performance benefit from afour-node cluster by a throughput improvement of 70%. This requires a secondvirtual CPU for the DB2 UDB server. The throughput improvement is limited bythe complete utilization of the eight CPUs of the LPAR.Related information


Detailed set up examples for the WebSphere environment performancetests

The detailed setup we performed to setup WebSphere Application Sever, Trade,and WebSphere Load Balancer, as well as the scripts we used, are provided here.

WebSphere setupFor our tests, we needed to setup the WebSphere dynamic caching services, enableservlet caching, and enable WebSphere as a server in a cluster.

Enabling WebSphere dynamic cache services

To enable the WebSphere dynamic cache services we did the following:1. Opened the WebSphere Administration Console from a browser window using

http://10/10/80/10:9060/ibm/console as the address2. Navigated to the Dynamic cache service screen (see Figure 17 on page 35)


3. Verified Enable service at server startup was selected (this is the defaultsetting)

4. Set our cache size to 2000 statements5. Selected OK

6. Saved changes to the master configuration7. Restarted WebSphere

Enabling a second WebSphere as a server within a clusterTo enable a second WebSphere as a server within a cluster, there are several linesthat must be added to the /IBM/WebSphere/Plugins/config/webserver1/plugin-cfg.xml file. The lines to be added are:<Server Name="server2" ConnectTimeout="0" ExtendedHandshake="false"

LoadBalanceWeight="1" MaxConnections="-1" WaitForContinue="false"><Transport Hostname="192.168.30.11" Port="9080" Protocol="http"/><Transport Hostname="192.168.30.11" Port="9443" Protocol="https">

<Property name="keyring" value="/IBM/WebSphere/Plugins/etc/plugin-key.kdb"/><Property name="stashfile" value="/IBM/WebSphere/Plugins/etc/plugin-key.sth"/>

</Transport></Server>

and they should be placed as follows (bold added for emphasis only):<ServerCluster Name="server1_Cluster" CloneSeparatorChange="false" ↓

LoadBalance="Round Robin" PostSizeLimit="-1" RemoveSpecialHeaders="true" ↓RetryInterval="60"><Server Name="server1" ConnectTimeout="0" ExtendedHandshake="false"

LoadBalanceWeight="1" MaxConnections="-1" WaitForContinue="false"><Transport Hostname="192.168.30.10" Port="9080" Protocol="http"/><Transport Hostname="192.168.30.10" Port="9443" Protocol="https"><Property name="keyring" value="/IBM/WebSphere/Plugins/etc/plugin-key.kdb"/><Property name="stashfile" value="/IBM/WebSphere/Plugins/etc/plugin-key.sth"/></Transport>

</Server><Server Name="server2" ConnectTimeout="0" ExtendedHandshake="false"

LoadBalanceWeight="1" MaxConnections="-1" WaitForContinue="false"><Transport Hostname="192.168.30.11" Port="9080" Protocol="http"/><Transport Hostname="192.168.30.11" Port="9443" Protocol="https">

<Property name="keyring" value="/IBM/WebSphere/Plugins/etc/plugin-key.kdb"/>

Figure 17. WebSphere Administrative Console screen


<Property name="stashfile" value="/IBM/WebSphere/Plugins/etc/plugin-key.sth"/></Transport>

</Server></ServerCluster>

Note: The ↓ symbol indicates that the text continues on the next line. These linesshould be entered on one line, not broken into multiple lines.

Trade setupThe following is the Trade tuning script we used for our DB2 UDB system.

Tuning script for DB2 UDB

tune_trade.shdb2 -v "connect to tradedb"#db2 -v "update db cfg for tradedb using DBHEAP 6992"db2 -v "update db cfg for tradedb using DBHEAP 25000"db2 -v "update db cfg for tradedb using CATALOGCACHE_SZ 282"#db2 -v "update db cfg for tradedb using LOGBUFSZ 4096"db2 -v "update db cfg for tradedb using LOGBUFSZ 8192"db2 -v "update db cfg for tradedb using BUFFPAGE 366190"db2 -v "update db cfg for tradedb using LOCKLIST 1000"db2 -v "update db cfg for tradedb using SORTHEAP 642"db2 -v "update db cfg for tradedb using STMTHEAP 2048"db2 -v "update db cfg for tradedb using PCKCACHESZ 7500"db2 -v "update db cfg for tradedb using MAXLOCKS 75"db2 -v "update db cfg for tradedb using MAXAPPLS 500"db2 -v "update db cfg for tradedb using LOGFILSIZ 5000"db2 -v "update db cfg for tradedb using LOGPRIMARY 6"db2 -v "update db cfg for tradedb using LOGSECOND 6"#db2 -v "update db cfg for tradedb using newlogpath e:"db2 -v "update db cfg for tradedb using SOFTMAX 70"db2 -v "update dbm cfg using MAXAGENTS 500"db2 -v "update dbm cfg using NUM_POOLAGENTS 250"db2 -v "update dbm cfg using MAX_QUERYDEGREE 1"db2 -v "update dbm cfg using FCM_NUM_BUFFERS 2048"db2 -v "update dbm cfg using FCM_NUM_RQB 6500"db2 -v "update dbm cfg using DFT_MON_LOCK OFF"db2 -v "update dbm cfg using DFT_MON_BUFPOOL ON"db2 -v "update dbm cfg using DFT_MON_STMT OFF"db2 -v "update dbm cfg using DFT_MON_TABLE OFF"db2 -v "update dbm cfg using DFT_MON_UOW OFF"db2 -v "alter bufferpool ibmdefaultbp size 1000"db2 -v "reorgchk update statistics on table all"db2 -v "connect reset"db2 -v "terminate"

Tuning script for WebSphere

The following is the Trade tuning script we used for our WebSphere system.

trade_tune.jacl

Note: The ↓ symbol indicates that the text continues on the next line. These linesshould be entered on one line, not broken into multiple lines.

#--------------------------------------------------------------------# Generic WebSphere Tuning Script#--------------------------------------------------------------------

Figure 18. Trade tuning script for WebSphere


## Author: Christopher Blythe## This script is designed to modify some of the most common# WebSphere configuration parameters and tuning knobs.# In order to tune the config parameters, simply change the values# provided below. This script assumes that all server names in a# cluster configuration are unique.## To invoke the script, type:# wsadmin -f tuneWAS.jacl <scope> <id># scope - 'cluster' or 'server'# id - name of target object within scope (ie. servername)## Examples:# wsadmin -f tuneWAS.jacl server server1## wsadmin -f tuneWAS.jacl cluster TradeCluster###--------------------------------------------------------------------

$AdminConfig setValidationLevel NONE

set buildDate "09212004"

puts "Starting script..."puts "Version: $buildDate"puts "Reading config parameters..."

#--------------------------------------------------------------------# COMMON CONFIG PARAMETERS# - Adjust these parameters based on the intended target system#--------------------------------------------------------------------# ORB properties (10,50,false)set minORBPool 10set maxORBPool 50set noLocalCopies true

# WebContainer Thread Pool (10,50)set minWebPool 50set maxWebPool 50#

HTTP KeepAlive settings (true, 100)set keepAliveEnabled trueset maxPersistentRequests -1

# Inactivity Timeouts for thread pools (3500)set inactivity 3500

# EJB Cache properties (2053)set ejbCacheSize 2053

# JVM propertiesset minHeap 1024set maxHeap 1024set verboseGC "false"set genericArgs ""

# OS Specific JVM optionsset IBMJDKoptions ""set SUNJDKoptions "-XX:MaxPermSize=64m -XX:MaxNewSize=680m -XX:NewSize=680m ↓

-XX:SurvivorRatio=16"set HPJDKoptions "-Xmn680m"

# SPECjAppServer2002 related generic JVM arguments


# -Dcom.ibm.ws.pm.batch=true# -Dcom.ibm.ws.pm.deferredcreate=true# -Dcom.ibm.CORBA.FragmentSize=0# Trade3 related generic JVM arguments# -Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true

# Transaction Service properties (120,60)set txTimeout 120set clientTimeout 60

# SystemOut and SystemErr log rollover type (SIZE)set rollover "NONE"

# TraceService settings {"*=all=disabled",20,1}set traceSpec "*=all=disabled"set traceRolloverSize 100set maxFiles 10

# Java2 Security (false for 5.1 and true for 6.0)set j2Security false

# PMI serviceset PMIstatus false

# Uninstall default applications# Possibly uninstall applications - DefaultApplication, ivtAppset uninstallApps trueset uninstallList [list ivtApp DefaultApplication Query]

# Parallel server startupset parallelStart false

#---------------------------------------------# Check/Print Usage#---------------------------------------------

proc printUsageAndExit {} {puts " "puts "Usage: wsadmin -f tuneWAS.jacl <cluster | server> <name>"exit

}

#---------------------------------------------# Misc Procedures#---------------------------------------------

proc getName {objectid} {set endIndex [expr [string first "(" $objectid] - 1]

return [string range $objectid 0 $endIndex]}

#---------------------------------------------# Parse command line arguments#---------------------------------------------

puts "Parsing command line arguments..."

if {[llength $argv] < 2} {printUsageAndExit

} else {set scope [lindex $argv 0]puts "Scope: ${scope}"

if {$scope == "cluster"} {set clustername [lindex $argv 1]


puts "Cluster: ${clustername}"} elseif {$scope == "server"} {

set servername [lindex $argv 1]puts "Server: ${servername}"

} else {puts "Error: Invalid Argument ($scope)"printUsageAndExit

}}

#---------------------------------------------------------------------# Base OS Specific JVM settings#---------------------------------------------------------------------

if {[string first "Windows" $env(os.name)] >= 0 } {set genericArgs [concat $genericArgs $IBMJDKoptions]

} elseif {$env(os.name) == "AIX"} {set genericArgs [concat $genericArgs $IBMJDKoptions]

} elseif {$env(os.name) == "Linux"} {set genericArgs [concat $genericArgs $IBMJDKoptions]

} elseif {$env(os.name) == "SunOS"} {set genericArgs [concat $genericArgs $SUNJDKoptions]

} elseif {$env(os.name) == "HP-UX"} {set genericArgs [concat $genericArgs $HPJDKoptions]

}#---------------------------------------------# Obtain server list#---------------------------------------------

puts ""puts "Obtaining server list..."

if {$scope == "cluster"} {set cluster [$AdminConfig getid "/ServerCluster:${clustername}/"]set temp [$AdminConfig showAttribute $cluster members]set memberList [split [string trim $temp "{ }"] " "]foreach member $memberList {

set memberName [getName $member]lappend serverList [$AdminConfig getid "/Server:${memberName}/"]

}} else {

set server [$AdminConfig getid "/Server:${servername}/"]lappend serverList $server

}

#---------------------------------------------# Print config properties#---------------------------------------------

puts ""puts "WebSphere configuration"puts "-----------------------"puts ""puts " Enforce Java2 Security: ${j2Security} "puts ""

puts "Servers:"foreach server $serverList {

puts " [getName $server]"}puts ""puts " EJB/ORB ----------------------------------------"puts " Min ORB Pool Size: ${minORBPool} "puts " Max ORB Pool Size: ${maxORBPool} "puts " EJB Cache Size: ${ejbCacheSize} "puts " NoLocalCopies: ${noLocalCopies} "


puts " Web --------------------------------------------"puts " Min WebContainer Pool Size: ${minWebPool} "puts " Max WebContainer Pool Size: ${maxWebPool} "puts " JVM --------------------------------------------"puts " Min JVM Heap Size: ${minHeap} "puts " Max JVM Heap Size: ${maxHeap} "puts " Verbose GC: ${verboseGC}"puts " Generic JVM Arguments: "puts " ${genericArgs}"puts " Transaction ------------------------------------"puts " Total Transaction Timeout: ${txTimeout} "puts " Client Inactivity Timeout: ${clientTimeout} "puts " Logging ----------------------------------------"puts " System Log Rollover Type: ${rollover} "puts " Trace Specification: ${traceSpec} "puts " Rollover Size: ${traceRolloverSize} "puts " Max Backup Files: ${maxFiles} "puts " Misc -------------------------------------------"puts " Enable PMI Service: ${PMIstatus} "puts " Pool Activity Timeouts: ${inactivity} "puts " Parallel Startup: ${parallelStart} "puts ""puts " Uninstall default apps: ${uninstallApps} "puts ""#---------------------------------------------# Modify cell parameters#---------------------------------------------

# Accessing cell based security configputs "Accessing security configuration..."set sec [$AdminConfig list Security]set attrs [subst {{enforceJava2Security $j2Security}}]puts "Updating security..."$AdminConfig modify $sec $attrs

#---------------------------------------------# Modify server parameters#---------------------------------------------

foreach server $serverList {set servername [getName $server]puts ""puts "Server: $servername"puts ""

# Accessing server startup configputs "Accessing server startup configuration..."puts "Parallel Startup (old/new): [$AdminConfig showAttribute $server ↓

parallelStartEnabled]/$parallelStart"set attrs [subst {{parallelStartEnabled $parallelStart}}]puts "Updating server startup..."puts ""$AdminConfig modify $server $attrs

# Accessing orb configputs "Accessing ORB configuration..."set orb [$AdminConfig list ObjectRequestBroker $server]set attrs [subst {{noLocalCopies $noLocalCopies}}]puts "ORB noLocalCopies (old/new): [$AdminConfig showAttribute ↓

$orb noLocalCopies]/$noLocalCopies"$AdminConfig modify $orb $attrsset orbPool [$AdminConfig showAttribute $orb threadPool]puts "ThreadPool MaxSize (old/new): [$AdminConfig showAttribute ↓

$orbPool maximumSize]/$maxORBPool"puts "ThreadPool MinSize (old/new): [$AdminConfig showAttribute ↓

$orbPool minimumSize]/$minORBPool"


puts "ThreadPool Inactivity Timeout (old/new): [$AdminConfig showAttribute ↓$orbPool inactivityTimeout]/$inactivity"

set attrs [subst {{maximumSize $maxORBPool} {minimumSize $minORBPool} ↓{inactivityTimeout $inactivity}}]

puts "Updating ORB..."puts " "$AdminConfig modify $orbPool $attrs

# Accessing web container thread pool configputs "Accessing web container thread pool configuration..."set tpList [$AdminConfig list ThreadPool $server]

set oI [lsearch -glob $tpList "*WebContainer*"]set webPool [lindex $tpList $oI]puts "ThreadPool MaxSize (old/new): [$AdminConfig showAttribute ↓

$webPool maximumSize]/$maxWebPool"puts "ThreadPool MinSize (old/new): [$AdminConfig showAttribute ↓

$webPool minimumSize]/$minWebPool"puts "ThreadPool Inactivity Timeout (old/new): [$AdminConfig showAttribute ↓

$webPool inactivityTimeout]/$inactivity"set attrs [subst {{maximumSize $maxWebPool} {minimumSize $minWebPool} ↓

{inactivityTimeout $inactivity}}]puts "Updating web container thread pool..."puts " "$AdminConfig modify $webPool $attrs

# Accessing HTTP keepalive configputs "Accessing HTTP KeepAlive configuration..."set HTTPInbound [$AdminConfig list HTTPInboundChannel $server]

set oI [lsearch -glob $HTTPInbound "*HTTP_2*"]set http2 [lindex $HTTPInbound $oI]puts "KeepAlive Enabled (old/new): [$AdminConfig showAttribute $http2 ↓

keepAlive]/$keepAliveEnabled"puts "Max Persistent Requests (old/new): [$AdminConfig showAttribute $http2 ↓

maximumPersistentRequests]/$maxPersistentRequests"set attrs [subst {{keepAlive $keepAliveEnabled} {maximumPersistentRequests ↓

$maxPersistentRequests}}]puts "Updating HTTP KeepAlives..."puts " "$AdminConfig modify $http2 $attrs

# Accessing EJB cacheputs "Accessing EJB cache..."set ejbCache [$AdminConfig list EJBCache $server]puts "Cache Size (old/new): [$AdminConfig showAttribute $ejbCache ↓

cacheSize]/$ejbCacheSize"set attrs [subst {{cacheSize $ejbCacheSize}}]puts "Updating EJB cache..."puts " "$AdminConfig modify $ejbCache $attrs

# Accessing Transaction Serviceputs "Accessing Transaction Service..."set txService [$AdminConfig list TransactionService $server]puts "Client Inactivity Timeout (old/new): [$AdminConfig ↓

showAttribute $txService clientInactivityTimeout]/$clientTimeout"puts "Total Transaction Lifetime Timeout (old/new): [$AdminConfig ↓

showAttribute $txService totalTranLifetimeTimeout]/$txTimeout"set attrs [subst {{clientInactivityTimeout $clientTimeout} ↓

{totalTranLifetimeTimeout $txTimeout}}]puts "Updating Transaction Service..."puts " "$AdminConfig modify $txService $attrs


# Accessing JVM configputs "Accessing JVM configuration..."set jvm [$AdminConfig list JavaVirtualMachine $server]puts "Initial Heap Size (old/new): [$AdminConfig showAttribute $jvm ↓

initialHeapSize]/$minHeap"puts "Maximum Heap Size (old/new): [$AdminConfig showAttribute $jvm ↓

maximumHeapSize]/$maxHeap"puts "VerboseGC Enabled (old/new): [$AdminConfig showAttribute $jvm ↓

verboseModeGarbageCollection]/$verboseGC"puts "Generic Arguments (old/new): [$AdminConfig showAttribute $jvm ↓

genericJvmArguments]/$genericArgs"set attrs [subst {{initialHeapSize $minHeap} {maximumHeapSize $maxHeap} ↓

{verboseModeGarbageCollection $verboseGC} {genericJvmArguments ↓"$genericArgs"}}]

puts "Updating JVM..."puts " "$AdminConfig modify $jvm $attrs # Accessing System log file configputs "Accessing System log file configuration..."set logList [$AdminConfig list StreamRedirect $server]

foreach log $logList {puts "[$AdminConfig showAttribute $log fileName] Rollover Type (old/new): ↓

[$AdminConfig showAttribute $log rolloverType]/${rollover}"set attrs [subst {{rolloverType $rollover}}]puts "Updating logs..."puts " "$AdminConfig modify $log $attrs

}

# Accessing Trace Service configputs "Accessing Trace Service configuration..."set traceService [$AdminConfig list TraceService $server]set traceLog [$AdminConfig showAttribute $traceService traceLog]puts "Trace Spec (old/new): [$AdminConfig showAttribute ↓

$traceService startupTraceSpecification]/$traceSpec"puts "Rollover File Size (old/new): [$AdminConfig showAttribute $traceLog ↓

rolloverSize]/$traceRolloverSize"puts "Max Backup Files (old/new): [$AdminConfig showAttribute $traceLog ↓

maxNumberOfBackupFiles]/$maxFiles"set attrs [subst {{startupTraceSpecification $traceSpec}}]set attrs2 [subst { {rolloverSize $traceRolloverSize} {maxNumberOfBackupFiles ↓

$maxFiles}}]puts "Updating Trace Service..."puts " "$AdminConfig modify $traceService $attrs$AdminConfig modify $traceLog $attrs2

# Accessing PMI service configputs "Accessing PMI service configuration..."set pmi [$AdminConfig list PMIService $server]puts "Enable (old/new): [$AdminConfig showAttribute $pmi enable]/$PMIstatus"set attrs [subst {{enable $PMIstatus}}]puts "Updating PMI..."puts " "$AdminConfig modify $pmi $attrs

# Uninstalling default applications# Possibly uninstall applications - DefaultApplication, ivtApp, UDDIRegistry, ↓

ManagementEJBif {$uninstallApps} {

puts "Uninstalling default applications..."set appList [$AdminApp list]foreach app $appList {

set oI [lsearch -glob $uninstallList $app]if {$oI > -1} {


puts "Removing application $app..."$AdminApp uninstall $app

}}

}}

puts ""puts "Script completed..."puts "Saving config..."

$AdminConfig save

Enabling the Trade application to use WebSphere dynamiccaching

Caching capabilities in Trade are disabled by default. However, you can change thedefault caching type by modifying the param-value in the runtime configuration touse either the DistributedMap interface or command bean caching. To change thedefault, edit the web.xml file in the /opt/IBM/WebSphere/AppServer/profiles/default/installedApps/wasserver1Node01Cell/trade.ear/tradeWeb.war/WEB-INF/directory. For example (bold added for emphasis only):</init-param>

<init-param id="InitParam_10"><description>Sets the data caching type. Legal values No Caching,

Command Caching and DistributedMap </description><param-name>cachingType</param-name><param-value>No Caching</param-value>

</init-param>

Firewall setupThe iptable rules we used for our two firewalls are detailed here.

Firewall 1 iptable rules

We used the following iptable rules for our back end firewall. This firewall isFirewall 1 seen in Figure 1 on page 7. It protected access to the WebSphereApplication Server Load Balancer, the Web Server, the WebSphere ApplicationServer Apache Server, and the DB2 UDB database.


DISPLAY IPTABLES:

firewall1:/etc/sysconfig/scripts # ./display-iptablesChain INPUT (policy DROP 679 packets, 48165 bytes)pkts bytes target prot opt in out source destination

4 336 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/019981 1856K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22

0 0 ACCEPT tcp -- * * 192.168.40.90 0.0.0.0/00 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.30.82

Chain FORWARD (policy ACCEPT 51M packets, 25G bytes)pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 34760 packets, 36M bytes)pkts bytes target prot opt in out source destination

4 336 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/00 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.40.900 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.30.82

ROUTE:

firewall1:/etc/sysconfig/scripts # routeKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface10.10.80.0 * 255.255.255.0 U 0 0 0 eth0192.168.30.0 * 255.255.255.0 U 0 0 0 eth1192.168.40.0 * 255.255.255.0 U 0 0 0 eth2link-local * 255.255.0.0 U 0 0 0 eth0loopback * 255.0.0.0 U 0 0 0 lo

/PROC/QETHfirewall1:/etc/sysconfig/scripts # cat /proc/qethdevices CHPID interface cardtype port chksum prio-q'ing rtr4 rtr6 fsz cnt-------------------------- ----- ---------- -------------- ---- ------ ---------- ---- ---- ----- -----0.0.1a00/0.0.1a01/0.0.1a02 x0A eth0 OSD_1000 0 sw always_q_2 pri no 64k 160.0.6100/0.0.6101/0.0.6102 x00 eth1 GuestLAN QDIO 0 sw always_q_2 no no 64k 160.0.6103/0.0.6104/0.0.6105 x01 eth2 GuestLAN QDIO 0 sw always_q_2 no no 64k 16

IPTABLES:

firewall1:/etc/sysconfig/scripts # cat start_iptables-FW1

iptables -P INPUT ACCEPTiptables -P OUTPUT ACCEPTiptables -P FORWARD ACCEPTiptables -F

###### INPUT

# to drop everything going into firewall

iptables -P INPUT DROPiptables -A INPUT -p icmp -j ACCEPTiptables -A INPUT -p tcp --dport 22 -s 0/0 -j ACCEPT

iptables -A INPUT -p tcp -s 192.168.40.90 -j ACCEPTiptables -A INPUT -p tcp -d 192.168.30.82 -j ACCEPT

# OUTPUTiptables -A OUTPUT -p icmp -j ACCEPTiptables -A OUTPUT -p tcp -d 192.168.40.90 -j ACCEPTiptables -A OUTPUT -p tcp -d 192.168.30.82 -j ACCEPT

Figure 19. iptable rules - Firewall 1


Firewall 2 iptable rules

We used the following iptable rules for our front end firewall. This firewall isFirewall 2 seen in Figure 1 on page 7 and provided protection between the clientmachines and the WebSphere Application Server Caching Proxy Server.

DISPLAY IPTABLES:

firewall2:/etc/sysconfig/scripts # ./display_iptablesChain INPUT (policy DROP 118 packets, 8376 bytes)pkts bytes target prot opt in out source destination

3629 334K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0tcp dpt:22

23 1932 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)pkts bytes target prot opt in out source destination

2714K 308M ACCEPT tcp -- * * 10.10.60.0/24 192.168.40.90 tcp dpt:804137K 4210M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

state RELATED,ESTABLISHED0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 6350 packets, 6606K bytes)pkts bytes target prot opt in out source destination

23 1932 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0

firewall2:/etc/sysconfig/scripts # ./display_iptablesChain INPUT (policy DROP 118 packets, 8376 bytes)pkts bytes target prot opt in out source destination3654 336K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2223 1932 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)pkts bytes target prot opt in out source destination2714K 308M ACCEPT tcp -- * * 10.10.60.0/24 192.168.40.90 tcp dpt:804137K 4210M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 6372 packets, 6609K bytes)pkts bytes target prot opt in out source destination23 1932 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0

ROUTE:

firewall2:/etc/sysconfig/scripts # routeKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface10.10.80.0 * 255.255.255.0 U 0 0 0 eth010.10.60.0 * 255.255.255.0 U 0 0 0 eth1192.168.40.0 * 255.255.255.0 U 0 0 0 eth2link-local * 255.255.0.0 U 0 0 0 eth0loopback * 255.0.0.0 U 0 0 0 lo

/PROC/QETH

firewall2:/etc/sysconfig/scripts # cat /proc/qethdevices CHPID interface cardtype port chksum prio-q'ing rtr4 rtr6 fsz cnt-------------------------- ----- ---------- -------------- ---- ------ ---------- ---- ---- ----- -----0.0.1a00/0.0.1a01/0.0.1a02 x0B eth0 OSD_1000 0 sw always_q_2 no no 64k 160.0.1b00/0.0.1b01/0.0.1b02 x0B eth1 OSD_1000 0 sw always_q_2 pri no 64k 160.0.6103/0.0.6104/0.0.6105 x00 eth2 GuestLAN QDIO 0 sw always_q_2 no no 64k 16

IPTABLES:firewall2:/etc/sysconfig/scripts # cat start_iptables_FW2

iptables -P INPUT ACCEPTiptables -P OUTPUT ACCEPTiptables -P FORWARD ACCEPT

Figure 20. iptable rules - Firewall 2


iptables -F

#### OUTPUTiptables -A OUTPUT -p icmp -j ACCEPT

###### INPUT

# to drop everything going into firewall

iptables -P INPUT DROP

# allow sshiptables -A INPUT -p tcp --dport 22 -s 0/0 -j ACCEPT

#iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A INPUT -p icmp -j ACCEPT

## FORWARD

iptables -P FORWARD DROP

# iptables -A FORWARD -j LOG --log-prefix "FORWETH1" --log-level alert

#iptables -A FORWARD -p tcp -i eth1 -o eth2 -d 192.168.40.90 -j ACCEPT

iptables -A FORWARD -p tcp --dport 80 -s 10.10.60.0/24 -d 192.168.40.90 -j ACCEPT

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A FORWARD -p icmp -j ACCEPT

Start iptables at system boot

To load the iptables ruleset at system reboot, we did the following:1. Using Yast, we disabled SUSEfirewall2 (the name of our firewall)2. Ran the script containing the ruleset to load the iptables.3. Ran the command to export the ruleset

iptables-save > /etc/sysconfig/iptables

4. Wrote the script to run this ruleset at boot. For example:#!/bin/bashiptables-restore < /etc/sysconfig/iptables

5. Changed the permissions of the script (our script name was bootiptables). Forexample:chmod 755 bootiptables

6. Placed our script in the /etc/init.d/ directory7. Enabled the execution of the script at boot by using Yast (Yast modules >

System > System services (Runlevel)

8. In Expert Mode, we unchecked loading for all rulevels for all entries of thefirewall

9. For the script, checked the boxes for runlevels B, 3, and 510. Rebooted your system11. Entered iptables -L -nv to display the rules.

WebSphere Load Balancer setupTo setup a single Apache server to work with Load Balancer, your ifconfig filemust be modified.eth0 Link encap:Ethernet HWaddr 00:09:6B:1A:C2:11

inet addr:10.10.80.80 Bcast:10.10.80.255 Mask:255.255.255.0inet6 addr: fe80::9:6b00:341a:c211/64 Scope:LinkUP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1


RX packets:26873 errors:0 dropped:0 overruns:0 frame:0TX packets:38275 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:1000RX bytes:3024755 (2.8 Mb) TX bytes:43256184 (41.2 Mb)

eth1 Link encap:Ethernet HWaddr 02:00:00:00:00:03inet addr:192.168.30.80 Bcast:192.168.30.255 Mask:255.255.255.0inet6 addr: fe80::200:0:900:3/64 Scope:LinkUP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1RX packets:32802244 errors:0 dropped:0 overruns:0 frame:0TX packets:32799805 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:1000RX bytes:3028590615 (2888.2 Mb) TX bytes:4077951685 (3889.0 Mb)

lo Link encap:Local Loopbackinet addr:127.0.0.1 Mask:255.0.0.0inet6 addr: ::1/128 Scope:HostUP LOOPBACK RUNNING MTU:16436 Metric:1RX packets:2442 errors:0 dropped:0 overruns:0 frame:0TX packets:2442 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:0RX bytes:218635 (213.5 Kb) TX bytes:218635 (213.5 Kb)

The /etc/hosts file needs to be as follows:## hosts This file describes a number of hostname-to-address# mappings for the TCP/IP subsystem. It is mostly# used at boot time, when no name servers are running.# On small systems, this file can be used instead of a# "named" name server.# Syntax:## IP-Address Full-Qualified-Hostname Short-Hostname#

127.0.0.1 localhost

# special IPv6 addresses::1 localhost ipv6-localhost ipv6-loopback

fe00::0 ipv6-localnet

ff00::0 ipv6-mcastprefixff02::1 ipv6-allnodesff02::2 ipv6-allroutersff02::3 ipv6-allhosts192.168.30.82 www.ptest.com10.10.80.82 www.ptest2.com192.168.30.100 webserver1.vlan1.com webserver1192.168.30.80 lbserver.pdl.pok.ibm.com lbserverlbserver:~ #

A start script and a stop script are needed for Load Balancer. Both scripts are runfrom the root. The start script we used was load_balancer_start.sh and lookedlike:#!/bin/bashdsserver startsleep 5dscontrol executor startdscontrol cluster add www.ptest.comdscontrol port add www.ptest.com@80dscontrol port add www.ptest.com@443dscontrol server add www.ptest.com@[email protected] server add www.ptest.com@[email protected] executor configure www.ptest.com


dscontrol manager startdscontrol advisor start http 80dscontrol server report www.ptest.com@[email protected] server status www.ptest.com@[email protected] eth1:0 192.168.30.82 netmask 255.255.255.0 up#ifconfigexit

The stop script we used was load_balancer_stop.sh and looked like:#!/bin/bash#dscontrol manager stopdscontrol executor stopdsserver stop

WebSphere Studio Workload Simulator scriptWe modified the WebSphere Studio Workload Simulator script as follows for ourtests.

Note that only a portion of the script file is shown here....start_transaction("login");startpage(4);thinktime(1000);//uid = URLEncode("uid:"+random(0,num_u - 1));//TODO: Make this random but better than above - must be random across all

clientsint clientnum;enter_critical_section();curClient = curClient + 1;if (curClient > topClient){curClient = botClient;}

clientnum = curClient;leave_critical_section();uid = URLEncode("uid:" + clientnum);postpage(""+hostname+"","/trade/app",1,close,0,start,"","uid=" +uid+ "&passwd=xxx&action=login","Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*","Referer: http://"+hostname+"/trade/app","Accept-Language: en-us","Content-Type: application/x-www-form-urlencoded","Accept-Encoding: gzip, deflate","User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)","Host: "+hostname+"","Connection: Keep-Alive");

endpage;end_transaction("login");...

Web.xmlWe modified the Web.xml file as follows for our tests.

Note that only a portion of the file is shown here....

<init-param id="InitParam_10"><description>Sets the data caching type. Legal values No Caching,

Command Caching and DistributedMap </description><param-name>cachingType</param-name>


<param-value>No Caching</param-value></init-param>...

Cachespec.xmlWe used the following cachespec.xml file for all our testing.<?xml version="1.0"?><!DOCTYPE cache SYSTEM "cachespec.dtd">



<cache><cache-entry>

<class>servlet</class><name>/app</name>

<cache-id><component id="action" type="parameter"><value>portfolio</value><required>true</required></component><component id="JSESSIONID" type="cookie"><required>true</required></component><property name="EdgeCacheable">true</property></cache-id><cache-id><component id="action" type="parameter"><value>portfolioNoEdge</value><required>true</required></component><component id="JSESSIONID" type="cookie"><required>true</required></component><property name="EdgeCacheable">false</property></cache-id>

<dependency-id>Holdings_UserID

<component id="action" type="parameter" ignore-value="true"><value>portfolio</value><required>true</required></component><component id="uidBean" type="session"><required>true</required></component></dependency-id>



<dependency-id>Holdings_UserID1<component id="action" type="parameter" ignore-value="true">

<value>portfolio</value><required>true</required>


</component><component id="uidBean" type="session"><required>true</required></component></dependency-id>

<dependency-id>Holdings_UserID<component id="action" type="parameter" ignore-value="true"><value>portfolioNoEdge</value><required>true</required></component><component id="uidBean" type="session"><required>true</required></component></dependency-id>



<cache-id><component id="action" type="parameter"><value>account</value><required>true</required></component><component id="JSESSIONID" type="cookie"><required>true</required></component><property name="EdgeCacheable">true</property></cache-id>

<dependency-id>Account_UserID

<component id="action" type="parameter" ignore-value="true"><value>account</value><required>true</required></component><component id="uidBean" type="session"><required>true</required></component></dependency-id>

<dependency-id>AccountProfile_UserID<component id="action" type="parameter" ignore-value="true">

<value>account</value><required>true</required></component><component id="uidBean" type="session"><required>true</required></component></dependency-id>



<cache-id><component id="action" type="parameter"><value>home</value><required>true</required></component><component id="JSESSIONID" type="cookie"><required>true</required></component><property name="EdgeCacheable">true</property></cache-id><dependency-id>Account_UserID

<component id="action" type="parameter" ignore-value="true"><value>home</value>


<required>true</required></component><component id="uidBean" type="session"><required>true</required></component></dependency-id><dependency-id>Holdings_UserID

<component id="action" type="parameter" ignore-value="true"><value>home</value><required>true</required></component><component id="uidBean" type="session"><required>true</required></component></dependency-id>

<cache-id>

<component id="action" type="parameter"><value>quotes</value><required>true</required></component><component id="symbols" type="parameter"><required>true</required></component><property name="EdgeCacheable">true</property></cache-id>

<dependency-id>AllQuotes<component id="action" type="parameter" ignore-value="true"><value>quotes</value><required>true</required></component></dependency-id>

<dependency-id>Quote_Symbol<component id="action" type="parameter" ignore-value="true"><value>quotes</value><required>true</required>

</component><component id="symbol" type="parameter">

<required>true</required></component>

</dependency-id></cache-entry>

<cache-entry>

<class>servlet</class><name>/register.jsp</name><property name="EdgeCacheable">true</property><cache-id><timeout>180</timeout></cache-id>

</cache-entry>

<cache-entry>

<class>servlet</class><name>/marketSummary.jsp</name><property name="EdgeCacheable">true</property>


<cache-id><priority>3</priority><timeout>180</timeout></cache-id><dependency-id>MarketSummary</dependency-id></cache-entry>



<cache-entry><class>servlet</class><name>/displayQuote.jsp</name><property name="EdgeCacheable">true</property><cache-id><component id="symbol" type="parameter"><required>true</required></component><priority>3</priority></cache-id>



<dependency-id>Quote_Symbol<component id="symbol" type="parameter"><required>true</required></component></dependency-id>

<dependency-id>AllQuotes</dependency-id></cache-entry>

<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.MarketSummaryCommand</name><cache-id><priority>3</priority><timeout>10</timeout></cache-id><dependency-id>MarketSummary</dependency-id></cache-entry>



<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.QuoteCommand</name><cache-id><component type="method" id="getSymbol">


<required>true</required></component><priority>3</priority></cache-id>



<dependency-id>Quote_Symbol<component id="getSymbol" type="method"><required>true</required></component></dependency-id>

<dependency-id>AllQuotes</dependency-id></cache-entry>

<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.UpdateQuotePriceCommand</name>

<invalidation>Quote_Symbol<component id="getSymbol" type="method"><required>true</required></component></invalidation></cache-entry>



<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.AccountCommand</name><cache-id><component type="method" id="getUserID"><required>true</required></component><priority>3</priority></cache-id>



<dependency-id>Account_UserID<component id="getUserID" type="method"><required>true</required></component></dependency-id>




<dependency-id>AllUsers</dependency-id></cache-entry>



<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.AccountProfileCommand</name><cache-id><component type="method" id="getUserID"><required>true</required></component><priority>3</priority></cache-id>



<dependency-id>AccountProfile_UserID<component id="getUserID" type="method"><required>true</required></component></dependency-id>

<dependency-id>AllUsers</dependency-id>

</cache-entry>

<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.HoldingsCommand</name><cache-id><component type="method" id="getUserID"><required>true</required></component><priority>3</priority></cache-id>



<dependency-id>Holdings_UserID<component id="getUserID" type="method"><required>true</required></component></dependency-id>

<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.OrdersCommand</name><cache-id><component type="method" id="getUserID"><required>true</required></component><priority>3</priority></cache-id>



<dependency-id>Orders_UserID<component id="getUserID" type="method"><required>true</required></component></dependency-id>

<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.LoginCommand</name>

<invalidation>Account_UserID<component id="getUserID" type="method"><required>true</required></component></invalidation></cache-entry><cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.LogoutCommand</name>

<invalidation>Account_UserID<component id="getUserID" type="method"><required>true</required></component></invalidation><invalidation>Holdings_UserID1<component id="getUserID" type="method"><required>true</required></component>


</invalidation>

</cache-entry>

<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.OrderCompletedCommand</name>

<invalidation>Account_UserID<component id="getUserID" type="method"><required>true</required></component></invalidation><invalidation>Holdings_UserID<component id="getUserID" type="method"><required>true</required></component></invalidation><invalidation>Orders_UserID<component id="getUserID" type="method"><required>true</required></component></invalidation><invalidation>ClosedOrders_UserID<component id="getUserID" type="method"><required>true</required></component></invalidation></cache-entry>

<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy>


<name>com.ibm.websphere.samples.trade.command.BuyCommand</name>

<invalidation>Orders_UserID<component id="getUserID" type="method"><required>true</required></component></invalidation></cache-entry>

<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.SellCommand</name>

<invalidation>Orders_UserID<component id="getUserID" type="method"><required>true</required></component></invalidation><invalidation>Holdings_UserID<component id="getUserID" type="method"><required>true</required></component></invalidation></cache-entry>

<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.UpdateAccountProfileCommand</name>

<invalidation>AccountProfile_UserID<component id="getUserID" type="method"><required>true</required></component></invalidation></cache-entry>



<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.ClosedOrdersCommand</name><cache-id><component type="method" id="getUserID"><required>true</required></component><priority>3</priority></cache-id>




<dependency-id>ClosedOrders_UserID<component id="getUserID" type="method"><required>true</required></component></dependency-id>



<cache-entry><class>command</class><sharing-policy>not-shared</sharing-policy><name>com.ibm.websphere.samples.trade.command.ResetTradeCommand</name>

<invalidation>AllQuotes</invalidation>

<invalidation>AllUsers</invalidation>

<invalidation>MarketSummary</invalidation></cache-entry>

</cache>

ibmproxy.confThe following excerpts show the areas of the imbproxy.conf file that weresignificant to our testing....# *** START NEW MAPPING RULES SECTION ***

#Proxy /* http://www.ptest.com/* :80Proxy /* http://192.168.30.82/* :80Proxy /* https://192.168.30.81/* :443ReversePass http://192.168.30.82/* http://192.168.40.90/*


#ReversePass http://192.168.30.82/* http://10.10.80.90/*ReversePass https://192.168.30.82/* https://192.168.40.90/*

Proxy http:*

# *** END NEW MAPPING RULES SECTION ***...# MaxSocketPerServer directive:## This sets the maximum number of open IDLE sockets to maintain to any# one origin server.# This is only used if the ServerConnPool is set on.## Default: 5# Syntax: MaxSocketPerServer <num>MaxSocketPerServer 1000

# ServerConnTimeout directive:## This is set to limit the time to keep an unused connection to a server.# This is only used if the ServerConnPool directive is set on.## Default: 10 seconds# Syntax: ServerConnTimeout <time value>ServerConnTimeout 5 seconds

Glossary for the WebSphere environment performance testsTerms used in the End-to-End Performance of a WebSphere Environment on Linuxon zSeries Including Edge Components paper are defined here.

ClusterClusters are groups of servers that are managed together and participate inworkload management. A cluster can contain nodes or individualapplication servers. A node is usually a separate server system with adistinct host IP address that is running one or more application servers.Clusters are responsible for balancing the workload among these servers.Servers that are a part of a cluster are called cluster members. When youinstall an application on a cluster, the application is automatically installedon each cluster member.

CPU loadThis percentage value means the CPU utilization caused by the Linuxsystem. The System Activity Reporting (SAR) package under Linuxsupplies this value.

DMZ Demilitarized zone. A DMZ is a network area that sits between anorganization’s internal network and an external network, usually theInternet. Access from the DMZ to the internal zone is as restricted aspossible. In our tests, only the proxy was able to access well-definedtargets in the internal zone from the DMZ.

EJB Enterprise Java Beans. Component architecture for development anddeployment of object-oriented, distributed, enterprise-level applications.

HTMLHypertext Markup Language. A markup language for hypertext indocuments on the Internet.


I/O usageThis value (used in blocks of 1 KB) indicates the traffic to the input andoutput media. The System Activity Reporting (SAR) package under Linuxsupplies this value.

JSP Java Server Pages. An extensible Web technology that uses template data,custom elements, scripting languages, and server side Java objects to returndynamic content to a client. Typically, the template data is HTML or XMLand, in many cases, the client is the Web browser.

Other sources of information for the WebSphere environmentperformance tests

Additional resources to provide information on the products, hardware, andsoftware discussed in this paper can be found in various books and at various Websites.

For information on WebSphere Application Server see:http://www.ibm.com/software/info1/websphere/index.jsp?tab=products/apptransaction

For information on Linux on zSeries see:www.ibm.com/servers/eserver/zseries/os/linux/

For information on z/VM see:www.vm.ibm.com

For information on the Trade 6.0 application see the IBM Redbook Using WebSphereExtended Deployment V6.0 to Build an On Demand Production Environment at:http://www.redbooks.ibm.com/abstracts/sg247153.html

It discusses Trade 6 installation. After installing the Trade 6, the Web applicationcontains details on the Trade 6 application architecture and other information.

For general instructions on installing and configuring the various components inthe topology, see the IBM RedBook WebSphere Application Server V6 Scalability andPerformance Handbook found at:http://www.redbooks.ibm.com/redbooks/pdfs/sg246392.pdf

For performance information for Trade on WebSphere Application Server see:http://www.ibm.com/software/webservers/appserv/was/performance.html

The caching proxy manuals are found at:http://www.ibm.com/software/webservers/appserv/doc/v602/ec/infocenter/index.html

For information on IBM open source projects see:www.ibm.com/developerworks/opensource/index.html

Notices for the WebSphere environment performance testsAdditional resources to provide information on the products, hardware, andsoftware discussed in this paper can be found in various books and various Websites.


http://www.ibm.com/software/info1/websphere/index.jsp?tab=products/ apptransaction

http://www.ibm.com/software/info1/websphere/index.jsp?tab=products/ apptransaction

http://www.ibm.com/servers/eserver/zseries/os/linux/

http://www.vm.ibm.com

http://www.redbooks.ibm.com/abstracts/sg247153.html

http://www.redbooks.ibm.com/redbooks/pdfs/sg246392.pdf

http://www.ibm.com/software/webservers/appserv/was/performance.html

http://www.ibm.com/software/webservers/appserv/doc/v602/ec/infocenter/index.html

http://www.ibm.com/developerworks/opensource/index.html

IBM, IBM eServer, IBM logo, DB2, DB2 Universal Database, DS8000, ECKD,FICON, HiperSockets, Performance Toolkit for z/VM, System Storage, System z,System z9, WebSphere, xSeries, and z/VM are trademarks or registered trademarksof International Business Machines Corporation of the United States, othercountries or both.

The following are trademarks or registered trademarks of other companies

Java and all Java-based trademarks and logos are trademarks of Sun Microsystems,Inc. in the United States, other countries or both.

UNIX is a registered trademark of The Open Group in the United States and othercountries.

Intel and Xeon are trademarks of Intel Corporation in the United States, othercountries or both.

Linux is a registered trademark of Linus Torvalds in the United States and othercountries.

Microsoft and Windows are registered trademarks of Microsoft Corporation in theUnited States, other countries, or both.

Other company, product and service names may be trademarks or service marks ofothers.

Information concerning non-IBM products was obtained from the suppliers of theirproducts or their published announcements. Questions on the capabilities of thenon-IBM products should be addressed with the suppliers.

IBM hardware products are manufactured from new parts, or new and serviceableused parts. Regardless, our warranty terms apply.

IBM may not offer the products, services or features discussed in this document inother countries, and the information may be subject to change without notice.Consult your local IBM business contact for information on the product or servicesavailable in your area.

All statements regarding IBM’s future direction and intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

Performance is in Internal Throughput Rate (ITR) ratio based on measurementsand projections using standard IBM benchmarks in a controlled environment. Theactual throughput that any user will experience will vary depending uponconsiderations such as the amount of multiprogramming in the user’s job stream,the I/O configuration, the storage configuration, and the workload processed.Therefore, no assurance can be given that an individual user will achievethroughput improvements equivalent to the performance ratios stated here.

Documents

End-to-End Performance of a WebSphere Environment