WebSphere Application Server Base Performance - IBM

WebSphere Application Server BasePerformance

��

ii WebSphere Application Server Base Performance

Contents

WebSphere Application Server BasePerformance . . . . . . . . . . . . . 1Introduction to the WebSphere Application Serverperformance tests . . . . . . . . . . . . . 1Summary for the WebSphere Application Serverperformance tests . . . . . . . . . . . . . 2Hardware and software configuration for theWebSphere Application Server performance tests . . 3

Environment . . . . . . . . . . . . . 4Workload description - Trade . . . . . . . . 6

System setup for the WebSphere Application Serverperformance tests . . . . . . . . . . . . . 6

WebSphere Studio Workload Simulator clientsetup . . . . . . . . . . . . . . . . 7Database setup . . . . . . . . . . . . 8WebSphere Application Server setup . . . . . 9

Results for the WebSphere Application Serverperformance tests . . . . . . . . . . . . . 9

Separating the network streams . . . . . . 10Modify the database layout . . . . . . . . 11Modify logging setup . . . . . . . . . . 12Disable AIO for WebSphere Application Server 13Workload generation . . . . . . . . . . 14WebSphere Application Server version 6.0.2versus version 6.1 . . . . . . . . . . . 16DB2 v8 versus DB2 v9 . . . . . . . . . . 17SLES9 versus SLES10 . . . . . . . . . . 18WebSphere Application Server 31-bit versus64-bit . . . . . . . . . . . . . . . 19OSA card versus HiperSockets . . . . . . . 21

Other sources of information for the WebSphereApplication Server performance tests . . . . . . 25Notices for the WebSphere environmentperformance tests . . . . . . . . . . . . 26

iii

iv WebSphere Application Server Base Performance

WebSphere Application Server Base Performance

The paper gathers Linux(R) end-to-end measurements for all of the components inthe path from the user accessing the WebSphere(R) Application Server system tothe database.

Published December 2007

These components are:v SUSE Linux Enterprise Server (SLES)v WebSphere Application Serverv Javav IBM DB2 Universal Database on Linux for IBM System z or on z/OS

We show how this set of products performs on a release-to-release basis and howthe performance can be improved.

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

WebSphere Application Server Base Performance (about 1.2 MB)

Introduction to the WebSphere Application Server performance testsThe purpose of this project was to measure the various release levels of productsused in the Trade workload. Our test results and recommendations are specific toour environment. Parameters useful in our environment might be useful in otherenvironments, but are dependent on application usage and system configuration.

Objectives

The objectives of this project were to gather Linux® end-to-end measurements forall of the components in the path from the WebSphere® Application Server useraccessing the system to the database. The products in the path are: SUSE LinuxEnterprise Server (SLES), WebSphere Application Server, Java™, and IBM® DB2Universal Database™ on Linux for System z® or on z/OS®.

We wanted to show how this set of products, which is needed to run theWebSphere Application Server Trade 6 benchmark on Linux for System z, performson a release-to-release basis.

The release-to-release comparison was intended to show the effect of new releaseson performance and identify the cause of any performance degradations.

Executive summary

With the database on z/OS, we saw significant improvements in throughput(External Throughput Rate (ETR) and Internal Throughput Rate (ITR)) when we:v Used WebSphere Application Server 6.1v Divided the network streams from the WebSphere Application Server to the

client and to the database

1

v Optimized the database layout, which demonstrates that the application itselfcan significantly contribute to performance improvements

v Introduced HiperSockets™ connections to the database server

Overall, we reached an improvement of about 70% even with the decrease inperformance that we experienced with SLES10.

With the database on Linux, the separation of the network streams generates avery high throughput, and accordingly, a very high CPU utilization on theWebSphere Application Server. This limits the success of further turning activity.With HiperSockets connections, we reached a full saturation of the CPUs.

Summary for the WebSphere Application Server performance testsAfter running the WebSphere Application Server performance tests on our testenvironment, we compiled a summary of our results and recommendations.

Our test results and recommendations are specific to our environment. Parametersuseful in our environment might be useful in other environments, but aredependent on application usage and system configuration. You will need todetermine what works best for your environment. For our detailed test resultsinformation, see “Results for the WebSphere Application Server performance tests”on page 9.

The following are our summary results:v WebSphere Application Server version 6.1 (31-bit) has a significant advantage

compared to version 6.0.2. This advantage seems to be a result of successfuloptimization leading to higher throughputs at lower cost. The change from 6.0.2to 6.1 (31-bit) can be highly recommended.

v Sharing one network card for all traffic was identified as a bottleneck. Using aseparate network card for the traffic to the client and another for the traffic tothe database results in a very good ETR improvement of 27%.

v The modification of the logging setup from the database on Linux showed thatmany smaller log files gave better throughputs than a reduced number of largelog files. Note that we did not consider recovery performance in this paper.

v We identified some database structures (indexes, data types, code pageconversion) from the database setup of DB2® on z/OS that could be optimized.Changing the z/OS database setup gave a throughput improvement of 12%.

v The I/O feature asynchronous I/O (AIO) on WebSphere has an advantage withboth databases. Because, in our case, WebSphere Application Server does verylittle disk I/O, the advantage comes from doing asynchronous network I/O.

v Using a higher number of client systems to generate the workload did notimprove the throughput.

v For the environment with the database on z/OS, the upgrade from DB2 v8 toDB v9 has no affect on performance. For the environment with the database onLinux, the message is not that simple. The new version is better optimized,which indicates a reduced CPU utilization, but the total throughput is slightlydecreased. So, DB2 v9 on Linux has a lower cost per transaction. This yields anincrease in ITR with a slight decrease in ETR.

v The upgrade of the WebSphere Application Server system to SLES10 leads to aslight decrease in throughput at the same CPU cost with the database on z/OS.With the database on Linux, the throughput decrease is less and the costincreases.

2 WebSphere Application Server Base Performance

v Switching a WebSphere 6.1 environment from 31-bit to 64-bit addressing usesadditional CPU and storage resources. Therefore, using 64-bit mode can only berecommended if the application needs more than 31-bit addressing toaccomplish its function. Further investigations are required to show whatthroughputs can be reached using a 64-bit WebSphere Application Server in anenvironment that requires 64-bit support.

v In general, the use of HiperSockets can be highly recommended. HiperSocketshas much lower latencies, because it is implemented in memory. This results inmuch higher network throughput, but HiperSockets have higher CPU costsbecause no work is off-loaded to the OSA Express card, which results in a lowerinternal throughout. Systems running at high CPU utilization might not benefitfrom the use of HiperSockets.

Hardware and software configuration for the WebSphere ApplicationServer performance tests

To perform our WebSphere Application Server tests, we created a customer-likeenvironment. We configured the hardware, software, network, and storage server.

Hardware and software

The following section details the hardware and software we used for our Linux onSystem z test runs.

Server hardware

IBM eServer™ zSeries® server

Two LPARs on a 16-way IBM System z9® Enterprise Class (z9® EC), model2094-S18, configured with:v LPAR 1 (WebSphere Application Server on Linux)

– 4 physical CPUs, dedicated– 4 GB central memory

v LPAR 2 (UDB database on z/OS or Linux)– 4 physical CPUs, dedicated– 12 GB central memory

v 2 OSA Express 2 Ethernet cardsv 4 dedicated ESCON® Express Channels

Network setup

v 2 - 4 client workstations on a 1 Gb Ethernet LANv 2 OSA Express 2 Ethernet cards on IBM System z, orv One OSA Express 2 Ethernet card and one HiperSockets connection

Storage server setup2105-F20, Disk Drive Modules - 18.2 GB each/10 K RPMsv 12 ECKD™ mod3s spread over 1 rank/LCUv 4 ESCON paths

WebSphere Application Server Base Performance 3

Server software

Table 1. Server software used

Product Version/Level

IBM DB2 Universal Database EnterpriseServer Edition (64-bit) for Linux on System z

DB2 v8.1.0.104 FixPak 11

IBM DB2 9 for Linux Unix and Windows® DB2 v9.1.0.0

IBM DB2 Universal Database EnterpriseServer Edition (64-bit) for z/OS

DB2 v8.1.0.104 FixPak 11

IBM DB2 v9 for z/OS DB2 v9.1.0.0 FixPak 0

SUSE Linux Enterprise Server (64-bit) SLES9

SUSE Linux Enterprise Server (64-bit) SLES10

WebSphere Application Server (31-bit) 6.1

WebSphere Application Server (64-bit) 6.1

z/OS v 1.8 CB02 Build July 21, 2006 + MAPMVSfix

Client hardwarev 1 IBM eServer xSeries® model 6565-2BU with a 667MHz Pentium® IIIv 1 xSeries model 6792-MHU with a 1.8 GHz Pentium 4

Client Software

Table 2 shows the client software used.

Table 2. Client software used

Product Version/Level

xSeries model 6565-2BU and 6792-MHU

Red Hat Enterprise Linux release 9

Trade workload 6.1

EnvironmentOur DB2 on z/OS environments we used for our WebSphere Application Servertests are shown here.

Figure 1 on page 5 depicts our environment using DB2 on z/OS and Figure 2 onpage 6 shows our environment used with separated network streams and DB2 onLinux on System z.


Figure 1. Trade 6 Linux for System z Performance Test Environment with DB2 on z/OS


Workload description - TradeTrade is an IBM-developed workload modeling an electronic brokerage providingonline securities trading.

Trade provides a real-world eBusiness application mix of Servlets, JSPs, EJBs, andJDBC data access, adjustable to emulate various work environments. Trade wasdeployed under WebSphere 6.02 and 6.1 and DB2 versions 8 and 9 served as thedatabase backend on Linux on System z and z/OS.

System setup for the WebSphere Application Server performance testsTo emulate a customer-like environment we needed to setup our network, theWebSphere Studio Workload Simulator client, the database, and WebSphereApplication Server.

Network setup

Our network setup used a variation of two OSA cards, which includes either one(see Figure 3 on page 7) or two (see Figure 4 on page 7) private networkconnections. For some of our tests, the second OSA card shown in Figure 4 wasreplaced by a HiperSockets connection.

Figure 2. Trade 6 Linux for System z Performance Test Environment with DB2 on Linux


WebSphere Studio Workload Simulator client setupWe used WebSphere Studio Workload Simulator clients to drive our performancetests.

Figure 3. Performance test environment with one shared OSA network card

Figure 4. Performance test environment with two OSA network cards


For measurements with WebSphere on Linux on System z, 60 WebSphere StudioWorkload Simulator clients were used, divided equally between two WebSphereStudio Workload Simulator engines (30 clients each). An additional scenario wasrun where four engines were used. 60 clients were divided equally among the fourengines (15 clients each).

Database setupTo perform our performance tests, we had to setup our database. Our databasewas spread across two different devices, each with its own file system.

Database layout

The database layout on the DB2 on z/OS LPAR was inherited from previous tests.We found that it differed in some areas from the layout used on the database onLinux.

We found that there were several differences between some of the Trade 6 databasesettings on DB2 on Linux versus the settings for DB2 on z/OS. We made thechanges described below because we expected them to improve the performance.

The following items were changed on the database on z/OS to make it comparableto the database on Linux on System z:v There is a difference in the database table structure between z/OS and Linux.

The ORDEREJB table on z/OS has three additional indexes defined that are notdefined on Linux DB2. (The extra indexes are: ORDERCLOSX, ORDEREXACTIDX, and ORDERETYPIDX.)This difference could be expected to cause higher processor utilization foroperations that cause changes to the indexes as well as longer overall responsetimes due to the hardening of the additional indexes at commit times. Becausethe updated indexes are serialized until they are committed, this could increaseoverall response times.We created the indexes so that they were the same on z/OS as they were onLinux.

v The ’varchar()’ data types default to padded versus not padded on z/OS. Thiscan affect processor utilization and latency by causing additional table accesses.We changed them to be unpadded on z/OS.

v The database on z/OS is stored in EBCDIC while on Linux it is stored in UTF-8.This causes data translation on the database on DB2 on z/OS. On Linux,however, the data is stored in UTF-8, which requires less translation overhead.The translation on the z/OS system uses additional processor. For head-to-headcomparisons we changed the z/OS database to also use UTF-8.

v The database on z/OS defaults to non-volatile. Under some cases this couldcause a sequential search of the entire file instead of the use of an index toaccess the information in the file. We changed the default to ″Volatile,″ whichalways causes the index to be used.

After making the changes described above, the databases were comparable andrepresented a standard setup for the Trade 6 workload.

Logging setup

On Linux we used one dedicated file system on a 3390 mod3 DASD for the DB2logs. The DB2 log files were set as shown below:


eight 128M logs or three 512M logs

On z/OS, DB2 is using two logs on two volumes with 3300 cylinders each.FEPDB2.LOGCOPY1.DS0A on volume DB9C37FEPDB2.LOGCOPY1.DS0B on volume DB9C38

WebSphere Application Server setupFor our performance tests, we used the default asynchronous I/O mode forWebSphere Application Server.

Asynchronous I/O

By default, WebSphere runs in asynchronous (async) I/O (AIO) mode because thelibibmaio.so is included in the WebSphere directory structure. To disable thisfeature, or to run in ″non-AIO″ mode, the file was renamed and removed from theWebSphere directory structure. This package provides facilities for performing AIOfor both files and sockets. For example:

mv libibmaio.so /tmp/libibmaio.so_ORGmv libibmaiodbg.so /tmp/libibmaiodbg.so_ORG

One of the major contributors to enhanced performance with AIO is in the form ofsaved context switches and thread scheduling due to the fact that threadsthemselves handle their own I/O with our fully AIO model. In our runs we didnot see a big change in performance when running with or without AIO. Thereason might be that in our setup we do not stress this feature enough.

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

In most cases we defined our results as External Transaction Rates (ETR) andInternal Transaction Rates (ITR). ETR is the raw workload results. ITR is the ETRdivided by the processor utilization rate, which shows the throughput as a perprocessor cost.

The tests we performed included:v “Separating the network streams” on page 10v “Modify the database layout” on page 11v “Modify logging setup” on page 12v “Disable AIO for WebSphere Application Server” on page 13v “Workload generation” on page 14v “WebSphere Application Server version 6.0.2 versus version 6.1” on page 16v “DB2 v8 versus DB2 v9” on page 17v “SLES9 versus SLES10” on page 18v “WebSphere Application Server 31-bit versus 64-bit” on page 19v “OSA card versus HiperSockets” on page 21


Separating the network streamsThe purpose of these test runs was to show the impact of separating the networkstreams between the clients and the WebSphere Application Server from thestreams between the WebSphere Application Server and the database.

One setup used one shared OSA network card for the connections from the clientsand the database to the WebSphere Application Server, the other one used twocards, one for each connection, for details see “Network setup” on page 6.

Observations

As seen in Figure 5, with two network cards, the transaction rate increases by 27%and the CPU load also increases. The slight decrease in ITR shows that the costsare increasing slightly.

Conclusion

Using a separate network card for the traffic to the client and to the databaseresults in a very good ETR improvement of 27%. This shows that sharing onenetwork card for all traffic is a bottleneck. All further measurements we performedwere done with separate network cards for the client and the database traffic. Theincrease in CPU cost (decreasing ITR) is so low it might be explained as just noise.Interestingly, both parameters are changing in the same direction, which isconsistent because an increase in instructions per transaction is always correlatedwith an increase in CPU load.

Network considerations

Figure 6 on page 11 shows the network throughput and packet rate summed upfor send and receive on all interfaces of the WebSphere Application Server for thescenarios with the database on z/OS where all traffic goes over one OSA card andwhere the traffic to the database goes over separate connections, either an OSA

Figure 5. ETR, ITR, and CPU utilization for the separating the network stream test case


card or HiperSockets.

For the scenario with the database on z/OS, the throughput increases up to 64%with the separate database connections and HiperSockets.Related information

WebSphere Application Server performance tests - hardware and softwareconfigurationTo perform our WebSphere Application Server tests, we created a customer-likeenvironment. We configured the hardware, software, network, and storage server.WebSphere Application Server performance tests - system setupTo emulate a customer-like environment we needed to setup our network, theWebSphere Studio Workload Simulator client, the database, and WebSphereApplication Server.WebSphere Application Server 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.

Modify the database layoutThe purpose of these test runs was to show the impact of the modification of thedatabase layout on DB2 on z/OS to better match the layout used on DB2 on Linux.

For details see “Database layout” on page 8.

Figure 6. Total network throughput on the WebSphere Application Server


Observations

The throughput increases by 12%, which is a significant improvement. The ITR isnearly the same showing very little additional cost.

Conclusion

The new database layout shows a significant improvement at nearly the same cost.This confirms that the implementation of the application contributes significantlyto the overall performance.Related information


Modify logging setupThe purpose of these test runs was to show the impact of modifying the databaselogging setup of DB2 on Linux.

For details see “Logging setup” on page 8.

Figure 7. ETR, ITR, and CPU utilization for the modify the database layout test case


Observations

The setup with the three larger log files has a 5% lower transaction throughput.The CPU utilization goes down in the same manner.

Conclusion

Unexpectedly, the setup with many small files gets higher transaction throughputeven though we have more log switches, and accordingly, higher processorutilization. One explanation could be that the log switch for the larger file takes adisproportionate amount of time versus the smaller file. Therefore, for ourremaining tests we kept the log setup with the many small files.Related information


Disable AIO for WebSphere Application ServerWebSphere Application Server uses AIO by default. The purpose of these tests wasto study the effect of disabling AIO for WebSphere Application Server.

Figure 8. ETR, ITR, and CPU utilization for the modify logging setup test case


Details are described in “WebSphere Application Server setup” on page 9.

Observations

The setup using AIO on WebSphere has a 9% higher transaction throughput atnearly the same CPU utilization cost.

Conclusion

AIO on WebSphere has an advantage. Because WebSphere Application Server doesnearly no disk I/O in our case, the advantage comes from asynchronous networkI/O.Related information


Workload generationFor measurements with WebSphere on Linux on System z, 60 WebSphere StudioWorkload Simulator users were used, divided equally between two WebSphereStudio Workload Simulator systems (30 users each). To study the effect of the

Figure 9. ETR, ITR, and CPU utilization for the disable AIO for WebSphere ApplicationServer test case


number of workload generators, a run was performed where four client systemswere used. 60 workload generators were divided equally among systems (15clients each).

Observations

The transaction throughput decreases by nearly 10%, which was not expected.However, the processor utilization on the server remained the same, which wasexpected. The CPU usage is also unexpectedly high, much higher than the increasein cycles per instruction, which results in a decreasing ITR.

Conclusion

Distributing the same workload over more client systems reduces the transactionthroughput. It was expected that the opposite would be true because contention onthe client side should be reduced. Theoretically, the server should see exactly thesame workload, even if the clients were slower to generate the workload. Becausethis is not the case, it indicates significantly decreasing ITR. It seems that it makesa difference for WebSphere Application Server that data structures from the sameuser on the same host are shared and they are not shared if the user logs on fromdifferent client machines.

Figure 10. ETR, ITR, and CPU utilization for the workload generation test case


Related information


WebSphere Application Server version 6.0.2 versus version6.1

The purpose of these test runs was to study the effect of switching the WebSphereApplication Server release from 6.0.2 to 6.1. The version of Trade was kept thesame.

Observations

WebSphere Application Server version 6.1 has a 20% higher transaction throughputcompared to version 6.0.2. The decreasing CPU utilization could be explained by asignificantly shorter path length of the WebSphere Application Server 6.1 and therelated Java.

Figure 11. ETR, ITR, and CPU utilization for the WebSphere Application Server version 6.0.2versus version 6.1 test case


Conclusion

WebSphere Application Server version 6.1 (31-bit) has a significant advantagecompared to version 6.0.2. It seems to be a result of successful optimization leadingto higher throughputs at lower cost. The change from 6.0.2 to 6.1 (31-bit) can behighly recommended.Related information


DB2 v8 versus DB2 v9The purpose of these test runs was to compare the affects of DB2 v8 versus DB2v9.

Observations

There are only slight differences in any parameter when upgrading from DB2 v8on z/OS to DB2 v9 on z/OS.

Figure 12. ETR, ITR, and CPU utilization for the DB2 v8 versus DB2 version 9 on Linux testcase


Conclusion

Upgrading the database from version 8 to version 9 has only a slight affect onperformance.Related information


SLES9 versus SLES10The purpose of these test runs was to compare the Linux releases SLES9 andSLES10 on the WebSphere Application Server. The distribution upgrade occurredon both the WebSphere Application Server and the Linux database server.

Observations

For the environment with the database on z/OS the throughput and CPU drops ina proportional manner allowing the costs to remain constant.

Figure 13. ETR, ITR, and CPU utilization for the SLES9 versus SLES10 with the DB2database on Linux test case


Observations

The environment with the database on Linux behaves similarly to the z/OSenvironment. However, the throughput drop is only about half and the CPUutilization stays constant, which leads to increasing cost.

Conclusion

The upgrade to SLES10 leads to increasing cost in our environment. Possiblereasons are that SLES10 starts more daemons, maybe the new udev layer(replacement for devfs) has some impact here (might be verified by usingcio_ignore), or the network performance with SLES10 is slightly worse.Related information


WebSphere Application Server 31-bit versus 64-bitThe purpose of these test runs was to compare the 31-bit and 64-bit versions ofWebSphere Application Server.

Figure 14. ETR, ITR, and CPU utilization for the SLES9 versus SLES10 with the DB2database on Linux test case


Observations

Using the 64-bit version of WebSphere Application Server results in a slightdegradation in transaction throughput but a significant increase in CPU utilization.

Conclusion

Switching a WebSphere Application Server 6.1 environment from 31-bit to 64-bitaddressing uses additional CPU and storage resources because at least alladdresses require twice the space. Therefore, using 64-bit mode can only berecommended if the application needs more than 31-bit addressing to accomplishits function. Further investigations are required to show what throughputs can bereached using a 64-bit WebSphere Application Server in an environment whichrequires 64-bit support.

Figure 15. ETR, ITR, and CPU utilization for the WebSphere Application Server 31-bit versus64-bit test case


Related information


OSA card versus HiperSocketsThe purpose of these test runs was to see the impact of using HiperSockets for theconnection between WebSphere Application Server and the database instead ofusing an OSA card.

WebSphere Application Server 6.1 (31-bit)

Observations

Use of HiperSockets with the 31-bit WebSphere Application Server environmentresults in a throughput improvement of nearly 20% as well as a fully utilizedsystem.

Conclusion

The use of HiperSockets can be highly recommended. By using HiperSockets, wewere able to fully utilize the WebSphere Application Server, which, unfortunately,

Figure 16. ETR, ITR, CPU utilization for the OSA card versus HiperSockets test case


limits the improvement. The fact that it is possible to increase the transactionthroughput by modifying the network connection type indicates that the networkconnection between the WebSphere Application Server and the database needs avery high bandwidth. The WebSphere Application Server itself is not a bottleneck.

WebSphere Application Server 6.1 (64-bit)

Observations

The use of HiperSockets as a connection type between the WebSphere ApplicationServer and the database leads to a large improvement of 33% in throughput andthe CPU load increases by 43%, which leads to a decreasing ITR and a highlyutilized system.

Conclusion

These results confirm that the connection between the WebSphere ApplicationServer and the database requires a high bandwidth, which can only be deliveredby HiperSockets.

Overall conclusion for OSA card versus HiperSockets

In general, the use of HiperSockets can be highly recommended. HiperSockets hasmuch lower latencies because it is implemented in memory. This results in muchhigher network throughput, but it is completely driven by the CPs. This means itis also related to higher CPU cost because no work can be delegated to the OSAExpress card. Systems running with fully utilized CPUs might not benefit from thischange.

Figure 17. ETR, ITR, and CPU utilization for the OSA card versus HiperSockets test case


Overall view - DB2 database on z/OS

Figure 18 shows the impact of the various changes for the environment with thedatabase on z/OS. The changes are cumulative to the right, meaning that thescenario labeled DB2 v9 also uses WebSphere Application Server 6.1, two OSAcards, and the new database layout.

The chart shows that significant improvements in throughput (ETR and ITR) camewhen we:1. Used WebSphere Application Server 6.12. Divided the network streams from the WebSphere Application Server to the

client and to the database3. Optimized the database layout4. Introduced HiperSockets connections to the database server

Overall, we reached an improvement of about 70% even with the decrease inthroughput seen with SLES10.

Figure 18. Impact on throughput with the database on z/OS


DB2 database on Linux

Figure 19 shows the impact of the various changes for the environment with thedatabase on Linux. The changes are cumulative to the right, meaning that thescenario labeled DB2 v9 also uses two OSA cards. All scenarios use WebSphereApplication Server 6.1.

Here we have less data points because we did not perform all runs with thedatabase on Linux. The overall improvement here is much lower because the entrypoint reaches a CPU utilization of 92% on the WebSphere Application server,which limits further improvements.

The ITR is stable. Even with the change to SLES, the ITR only decreases slightly.The change to HiperSockets connections could not improve the throughput asimpressively as with the database on z/OS because the WebSphere ApplicationServer was CPU constrained.

Figure 19. Impact on throughput with the database on Linux


Related information


Other sources of information for the WebSphere Application Serverperformance 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 Linux on System z see:www.ibm.com/systems/z/os/linux/

For information on WebSphere Application Server see:www.ibm.com/software/webservers/appserv/was/

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

Redbooks® from www.redbooks.ibm.com:v WebSphere Application Server V6.1: Planning and Design

www.redbooks.ibm.com/abstracts/sg247305.htmlv WebSphere Application Server V6.1: System Management and Configuration

www.redbooks.ibm.com/abstracts/sg247304.html

For information on the Trade 6.0 application, see the IBM Redbook UsingWebSphere Extended Deployment V6.0 to Build an On Demand Production Environmentat: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


http://www.ibm.com/systems/z/os/linux/

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

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

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



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

http://www.ibm.com/software/webservers/appserv/was/performance.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.

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.


WebSphere Application Server Base Performance - IBM

Documents

Transcript of WebSphere Application Server Base Performance - IBM