WebSphere Application Server Base Performance

Transcription

1 WebSphere Application Server Base Performance

2 ii WebSphere Application Server Base Performance

3 Contents WebSphere Application Server Base Performance Introduction to the WebSphere Application Server performance tests Summary for the WebSphere Application Server performance tests Hardware and software configuration for the WebSphere Application Server performance tests.. 3 Environment Workload description - Trade System setup for the WebSphere Application Server performance tests WebSphere Studio Workload Simulator client setup Database setup WebSphere Application Server setup Results for the WebSphere Application Server performance tests Separating the network streams Modify the database layout Modify logging setup Disable AIO for WebSphere Application Server 13 Workload generation WebSphere Application Server version versus version DB2 v8 versus DB2 v SLES9 versus SLES WebSphere Application Server 31-bit versus 64-bit OSA card versus HiperSockets Other sources of information for the WebSphere Application Server performance tests Notices for the WebSphere environment performance tests iii

4 iv WebSphere Application Server Base Performance

5 WebSphere Application Server Base Performance The paper gathers Linux(R) end-to-end measurements for all of the components in the path from the user accessing the WebSphere(R) Application Server system to the database. Published December 2007 These components are: v SUSE Linux Enterprise Server (SLES) v WebSphere Application Server v Java v 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 how the performance can be improved. To view or download the PDF version of this document, click on the following link: WebSphere Application Server Base Performance (about 1.2 MB) Introduction to the WebSphere Application Server performance tests The purpose of this project was to measure the various release levels of products used in the Trade workload. Our test results and recommendations are specific to our environment. Parameters useful in our environment might be useful in other environments, but are dependent on application usage and system configuration. Objectives The objectives of this project were to gather Linux end-to-end measurements for all of the components in the path from the WebSphere Application Server user accessing the system to the database. The products in the path are: SUSE Linux Enterprise Server (SLES), WebSphere Application Server, Java, and IBM DB2 Universal Database on Linux for System z or on z/os. We wanted to show how this set of products, which is needed to run the WebSphere Application Server Trade 6 benchmark on Linux for System z, performs on a release-to-release basis. The release-to-release comparison was intended to show the effect of new releases on 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.1 v Divided the network streams from the WebSphere Application Server to the client and to the database 1

6 v v Optimized the database layout, which demonstrates that the application itself can significantly contribute to performance improvements Introduced HiperSockets connections to the database server Overall, we reached an improvement of about 70% even with the decrease in performance that we experienced with SLES10. With the database on Linux, the separation of the network streams generates a very high throughput, and accordingly, a very high CPU utilization on the WebSphere 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 tests After running the WebSphere Application Server performance tests on our test environment, we compiled a summary of our results and recommendations. Our test results and recommendations are specific to our environment. Parameters useful in our environment might be useful in other environments, but are dependent on application usage and system configuration. You will need to determine what works best for your environment. For our detailed test results information, 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 This advantage seems to be a result of successful optimization leading to higher throughputs at lower cost. The change from to 6.1 (31-bit) can be highly recommended. v Sharing one network card for all traffic was identified as a bottleneck. Using a separate network card for the traffic to the client and another for the traffic to the database results in a very good ETR improvement of 27%. v The modification of the logging setup from the database on Linux showed that many smaller log files gave better throughputs than a reduced number of large log files. Note that we did not consider recovery performance in this paper. v We identified some database structures (indexes, data types, code page conversion) 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 with both databases. Because, in our case, WebSphere Application Server does very little 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 not improve the throughput. v For the environment with the database on z/os, the upgrade from DB2 v8 to DB v9 has no affect on performance. For the environment with the database on Linux, the message is not that simple. The new version is better optimized, which indicates a reduced CPU utilization, but the total throughput is slightly decreased. So, DB2 v9 on Linux has a lower cost per transaction. This yields an increase in ITR with a slight decrease in ETR. v The upgrade of the WebSphere Application Server system to SLES10 leads to a slight 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 cost increases. 2 WebSphere Application Server Base Performance

7 v v Switching a WebSphere 6.1 environment from 31-bit to 64-bit addressing uses additional CPU and storage resources. Therefore, using 64-bit mode can only be recommended if the application needs more than 31-bit addressing to accomplish its function. Further investigations are required to show what throughputs can be reached using a 64-bit WebSphere Application Server in an environment that requires 64-bit support. In general, the use of HiperSockets can be highly recommended. HiperSockets has much lower latencies, because it is implemented in memory. This results in much higher network throughput, but HiperSockets have higher CPU costs because no work is off-loaded to the OSA Express card, which results in a lower internal throughout. Systems running at high CPU utilization might not benefit from the use of HiperSockets. Hardware and software configuration for the WebSphere Application Server performance tests To perform our WebSphere Application Server tests, we created a customer-like environment. 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 on System z test runs. Server hardware IBM eserver zseries server Two LPARs on a 16-way IBM System z9 Enterprise Class (z9 EC), model 2094-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 cards v 4 dedicated ESCON Express Channels Network setup v 2-4 client workstations on a1gbethernet LAN v 2 OSA Express 2 Ethernet cards on IBM System z, or v One OSA Express 2 Ethernet card and one HiperSockets connection Storage server setup 2105-F20, Disk Drive Modules GB each/10 K RPMs v 12 ECKD mod3s spread over 1 rank/lcu v 4 ESCON paths WebSphere Application Server Base Performance 3

8 Server software Table 1. Server software used Product IBM DB2 Universal Database Enterprise Server Edition (64-bit) for Linux on System z IBM DB2 9 for Linux Unix and Windows IBM DB2 Universal Database Enterprise Server Edition (64-bit) for z/os Version/Level DB2 v FixPak 11 DB2 v DB2 v FixPak 11 IBM DB2 v9 for z/os DB2 v FixPak 0 SUSE Linux Enterprise Server (64-bit) SUSE Linux Enterprise Server (64-bit) SLES9 SLES10 WebSphere Application Server (31-bit) 6.1 WebSphere Application Server (64-bit) 6.1 z/os v 1.8 CB02 Build July 21, MAPMVS fix Client hardware v 1 IBM eserver xseries model BU with a 667MHz Pentium III v 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 BU and 6792-MHU Red Hat Enterprise Linux release 9 Trade workload 6.1 Environment Our DB2 on z/os environments we used for our WebSphere Application Server tests are shown here. Figure 1 on page 5 depicts our environment using DB2 on z/os and Figure 2 on page 6 shows our environment used with separated network streams and DB2 on Linux on System z. 4 WebSphere Application Server Base Performance

9 Figure 1. Trade 6 Linux for System z Performance Test Environment with DB2 on z/os WebSphere Application Server Base Performance 5

10 Figure 2. Trade 6 Linux for System z Performance Test Environment with DB2 on Linux Workload description - Trade Trade is an IBM-developed workload modeling an electronic brokerage providing online securities trading. Trade provides a real-world ebusiness application mix of Servlets, JSPs, EJBs, and JDBC data access, adjustable to emulate various work environments. Trade was deployed under WebSphere 6.02 and 6.1 and DB2 versions 8 and 9 served as the database backend on Linux on System z and z/os. System setup for the WebSphere Application Server performance tests To emulate a customer-like environment we needed to setup our network, the WebSphere Studio Workload Simulator client, the database, and WebSphere Application 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 network connections. For some of our tests, the second OSA card shown in Figure 4 was replaced by a HiperSockets connection. 6 WebSphere Application Server Base Performance

11 Figure 3. Performance test environment with one shared OSA network card Figure 4. Performance test environment with two OSA network cards WebSphere Studio Workload Simulator client setup We used WebSphere Studio Workload Simulator clients to drive our performance tests. WebSphere Application Server Base Performance 7

12 For measurements with WebSphere on Linux on System z, 60 WebSphere Studio Workload Simulator clients were used, divided equally between two WebSphere Studio Workload Simulator engines (30 clients each). An additional scenario was run where four engines were used. 60 clients were divided equally among the four engines (15 clients each). Database setup To perform our performance tests, we had to setup our database. Our database was 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 on Linux. We found that there were several differences between some of the Trade 6 database settings on DB2 on Linux versus the settings for DB2 on z/os. We made the changes described below because we expected them to improve the performance. The following items were changed on the database on z/os to make it comparable to 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 not defined on Linux DB2. (The extra indexes are: ORDERCLOSX, ORDER EXACTIDX, and ORDERETYPIDX.) This difference could be expected to cause higher processor utilization for operations that cause changes to the indexes as well as longer overall response times due to the hardening of the additional indexes at commit times. Because the updated indexes are serialized until they are committed, this could increase overall response times. We created the indexes so that they were the same on z/os as they were on Linux. v The varchar() data types default to padded versus not padded on z/os. This can 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-head comparisons 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 could cause a sequential search of the entire file instead of the use of an index to access the information in the file. We changed the default to Volatile, which always causes the index to be used. After making the changes described above, the databases were comparable and represented 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 DB2 logs. The DB2 log files were set as shown below: 8 WebSphere Application Server Base Performance

13 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 DB9C37 FEPDB2.LOGCOPY1.DS0B on volume DB9C38 WebSphere Application Server setup For our performance tests, we used the default asynchronous I/O mode for WebSphere Application Server. Asynchronous I/O By default, WebSphere runs in asynchronous (async) I/O (AIO) mode because the libibmaio.so is included in the WebSphere directory structure. To disable this feature, or to run in non-aio mode, the file was renamed and removed from the WebSphere directory structure. This package provides facilities for performing AIO for both files and sockets. For example: mv libibmaio.so /tmp/libibmaio.so_org mv libibmaiodbg.so /tmp/libibmaiodbg.so_org One of the major contributors to enhanced performance with AIO is in the form of saved context switches and thread scheduling due to the fact that threads themselves handle their own I/O with our fully AIO model. In our runs we did not see a big change in performance when running with or without AIO. The reason might be that in our setup we do not stress this feature enough. Results for the WebSphere Application Server performance tests After performing our WebSphere Application Server environment performance tests, we charted our test results, interpreted the results, and created recommendations. In most cases we defined our results as External Transaction Rates (ETR) and Internal Transaction Rates (ITR). ETR is the raw workload results. ITR is the ETR divided by the processor utilization rate, which shows the throughput as a per processor cost. The tests we performed included: v Separating the network streams on page 10 v Modify the database layout on page 11 v Modify logging setup on page 12 v Disable AIO for WebSphere Application Server on page 13 v Workload generation on page 14 v WebSphere Application Server version versus version 6.1 on page 16 v DB2 v8 versus DB2 v9 on page 17 v SLES9 versus SLES10 on page 18 v WebSphere Application Server 31-bit versus 64-bit on page 19 v OSA card versus HiperSockets on page 21 WebSphere Application Server Base Performance 9

14 Separating the network streams The purpose of these test runs was to show the impact of separating the network streams between the clients and the WebSphere Application Server from the streams between the WebSphere Application Server and the database. One setup used one shared OSA network card for the connections from the clients and the database to the WebSphere Application Server, the other one used two cards, 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 costs are increasing slightly. Conclusion Using a separate network card for the traffic to the client and to the database results in a very good ETR improvement of 27%. This shows that sharing one network card for all traffic is a bottleneck. All further measurements we performed were done with separate network cards for the client and the database traffic. The increase 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 is consistent because an increase in instructions per transaction is always correlated with an increase in CPU load. Network considerations 10 WebSphere Application Server Base Performance Figure 5. ETR, ITR, and CPU utilization for the separating the network stream test case Figure 6 on page 11 shows the network throughput and packet rate summed up for send and receive on all interfaces of the WebSphere Application Server for the scenarios with the database on z/os where all traffic goes over one OSA card and where the traffic to the database goes over separate connections, either an OSA

15 card or HiperSockets. Figure 6. Total network throughput on the WebSphere Application Server 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 software configuration To perform our WebSphere Application Server tests, we created a customer-like environment. We configured the hardware, software, network, and storage server. WebSphere Application Server performance tests - system setup To emulate a customer-like environment we needed to setup our network, the WebSphere Studio Workload Simulator client, the database, and WebSphere Application Server. WebSphere Application Server performance tests - other sources of information Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. Modify the database layout The purpose of these test runs was to show the impact of the modification of the database layout on DB2 on z/os to better match the layout used on DB2 on Linux. For details see Database layout on page 8. WebSphere Application Server Base Performance 11

16 Figure 7. ETR, ITR, and CPU utilization for the modify the database layout test case Observations The throughput increases by 12%, which is a significant improvement. The ITR is nearly 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 significantly to the overall performance. Related information WebSphere Application Server performance tests - hardware and software configuration To perform our WebSphere Application Server tests, we created a customer-like environment. We configured the hardware, software, network, and storage server. WebSphere Application Server performance tests - system setup To emulate a customer-like environment we needed to setup our network, the WebSphere Studio Workload Simulator client, the database, and WebSphere Application Server. WebSphere Application Server performance tests - other sources of information Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. Modify logging setup The purpose of these test runs was to show the impact of modifying the database logging setup of DB2 on Linux. For details see Logging setup on page WebSphere Application Server Base Performance

17 Figure 8. ETR, ITR, and CPU utilization for the modify logging setup 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 throughput even though we have more log switches, and accordingly, higher processor utilization. One explanation could be that the log switch for the larger file takes a disproportionate amount of time versus the smaller file. Therefore, for our remaining tests we kept the log setup with the many small files. Related information WebSphere Application Server performance tests - hardware and software configuration To perform our WebSphere Application Server tests, we created a customer-like environment. We configured the hardware, software, network, and storage server. WebSphere Application Server performance tests - system setup To emulate a customer-like environment we needed to setup our network, the WebSphere Studio Workload Simulator client, the database, and WebSphere Application Server. WebSphere Application Server performance tests - other sources of information Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. Disable AIO for WebSphere Application Server WebSphere Application Server uses AIO by default. The purpose of these tests was to study the effect of disabling AIO for WebSphere Application Server. WebSphere Application Server Base Performance 13

18 Details are described in WebSphere Application Server setup on page 9. Figure 9. ETR, ITR, and CPU utilization for the disable AIO for WebSphere Application Server test case Observations The setup using AIO on WebSphere has a 9% higher transaction throughput at nearly the same CPU utilization cost. Conclusion AIO on WebSphere has an advantage. Because WebSphere Application Server does nearly no disk I/O in our case, the advantage comes from asynchronous network I/O. Related information WebSphere Application Server performance tests - hardware and software configuration To perform our WebSphere Application Server tests, we created a customer-like environment. We configured the hardware, software, network, and storage server. WebSphere Application Server performance tests - system setup To emulate a customer-like environment we needed to setup our network, the WebSphere Studio Workload Simulator client, the database, and WebSphere Application Server. WebSphere Application Server performance tests - other sources of information Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. Workload generation For measurements with WebSphere on Linux on System z, 60 WebSphere Studio Workload Simulator users were used, divided equally between two WebSphere Studio Workload Simulator systems (30 users each). To study the effect of the 14 WebSphere Application Server Base Performance

19 number of workload generators, a run was performed where four client systems were used. 60 workload generators were divided equally among systems (15 clients each). Figure 10. ETR, ITR, and CPU utilization for the workload generation test case Observations The transaction throughput decreases by nearly 10%, which was not expected. However, the processor utilization on the server remained the same, which was expected. The CPU usage is also unexpectedly high, much higher than the increase in cycles per instruction, which results in a decreasing ITR. Conclusion Distributing the same workload over more client systems reduces the transaction throughput. It was expected that the opposite would be true because contention on the client side should be reduced. Theoretically, the server should see exactly the same workload, even if the clients were slower to generate the workload. Because this is not the case, it indicates significantly decreasing ITR. It seems that it makes a difference for WebSphere Application Server that data structures from the same user on the same host are shared and they are not shared if the user logs on from different client machines. WebSphere Application Server Base Performance 15

20 Related information WebSphere Application Server performance tests - hardware and software configuration To perform our WebSphere Application Server tests, we created a customer-like environment. We configured the hardware, software, network, and storage server. WebSphere Application Server performance tests - system setup To emulate a customer-like environment we needed to setup our network, the WebSphere Studio Workload Simulator client, the database, and WebSphere Application Server. WebSphere Application Server performance tests - other sources of information Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. WebSphere Application Server version versus version 6.1 The purpose of these test runs was to study the effect of switching the WebSphere Application Server release from to 6.1. The version of Trade was kept the same. Figure 11. ETR, ITR, and CPU utilization for the WebSphere Application Server version versus version 6.1 test case Observations WebSphere Application Server version 6.1 has a 20% higher transaction throughput compared to version The decreasing CPU utilization could be explained by a significantly shorter path length of the WebSphere Application Server 6.1 and the related Java. 16 WebSphere Application Server Base Performance

21 Conclusion WebSphere Application Server version 6.1 (31-bit) has a significant advantage compared to version It seems to be a result of successful optimization leading to higher throughputs at lower cost. The change from to 6.1 (31-bit) can be highly recommended. Related information WebSphere Application Server performance tests - hardware and software configuration To perform our WebSphere Application Server tests, we created a customer-like environment. We configured the hardware, software, network, and storage server. WebSphere Application Server performance tests - system setup To emulate a customer-like environment we needed to setup our network, the WebSphere Studio Workload Simulator client, the database, and WebSphere Application Server. WebSphere Application Server performance tests - other sources of information Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. DB2 v8 versus DB2 v9 The purpose of these test runs was to compare the affects of DB2 v8 versus DB2 v9. Figure 12. ETR, ITR, and CPU utilization for the DB2 v8 versus DB2 version 9 on Linux test case Observations There are only slight differences in any parameter when upgrading from DB2 v8 on z/os to DB2 v9 on z/os. WebSphere Application Server Base Performance 17

22 Conclusion Upgrading the database from version 8 to version 9 has only a slight affect on performance. Related information WebSphere Application Server performance tests - hardware and software configuration To perform our WebSphere Application Server tests, we created a customer-like environment. We configured the hardware, software, network, and storage server. WebSphere Application Server performance tests - system setup To emulate a customer-like environment we needed to setup our network, the WebSphere Studio Workload Simulator client, the database, and WebSphere Application Server. WebSphere Application Server performance tests - other sources of information Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. SLES9 versus SLES10 The purpose of these test runs was to compare the Linux releases SLES9 and SLES10 on the WebSphere Application Server. The distribution upgrade occurred on both the WebSphere Application Server and the Linux database server. Figure 13. ETR, ITR, and CPU utilization for the SLES9 versus SLES10 with the DB2 database on Linux test case Observations For the environment with the database on z/os the throughput and CPU drops in a proportional manner allowing the costs to remain constant. 18 WebSphere Application Server Base Performance

23 Figure 14. ETR, ITR, and CPU utilization for the SLES9 versus SLES10 with the DB2 database on Linux test case Observations The environment with the database on Linux behaves similarly to the z/os environment. However, the throughput drop is only about half and the CPU utilization stays constant, which leads to increasing cost. Conclusion The upgrade to SLES10 leads to increasing cost in our environment. Possible reasons are that SLES10 starts more daemons, maybe the new udev layer (replacement for devfs) has some impact here (might be verified by using cio_ignore), or the network performance with SLES10 is slightly worse. Related information WebSphere Application Server performance tests - hardware and software configuration To perform our WebSphere Application Server tests, we created a customer-like environment. We configured the hardware, software, network, and storage server. WebSphere Application Server performance tests - system setup To emulate a customer-like environment we needed to setup our network, the WebSphere Studio Workload Simulator client, the database, and WebSphere Application Server. WebSphere Application Server performance tests - other sources of information Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. WebSphere Application Server 31-bit versus 64-bit The purpose of these test runs was to compare the 31-bit and 64-bit versions of WebSphere Application Server. WebSphere Application Server Base Performance 19

24 Figure 15. ETR, ITR, and CPU utilization for the WebSphere Application Server 31-bit versus 64-bit test case Observations Using the 64-bit version of WebSphere Application Server results in a slight degradation in transaction throughput but a significant increase in CPU utilization. Conclusion Switching a WebSphere Application Server 6.1 environment from 31-bit to 64-bit addressing uses additional CPU and storage resources because at least all addresses require twice the space. Therefore, using 64-bit mode can only be recommended if the application needs more than 31-bit addressing to accomplish its function. Further investigations are required to show what throughputs can be reached using a 64-bit WebSphere Application Server in an environment which requires 64-bit support. 20 WebSphere Application Server Base Performance

25 Related information WebSphere Application Server performance tests - hardware and software configuration To perform our WebSphere Application Server tests, we created a customer-like environment. We configured the hardware, software, network, and storage server. WebSphere Application Server performance tests - system setup To emulate a customer-like environment we needed to setup our network, the WebSphere Studio Workload Simulator client, the database, and WebSphere Application Server. WebSphere Application Server performance tests - other sources of information Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. OSA card versus HiperSockets The purpose of these test runs was to see the impact of using HiperSockets for the connection between WebSphere Application Server and the database instead of using an OSA card. WebSphere Application Server 6.1 (31-bit) Figure 16. ETR, ITR, CPU utilization for the OSA card versus HiperSockets test case Observations Use of HiperSockets with the 31-bit WebSphere Application Server environment results in a throughput improvement of nearly 20% as well as a fully utilized system. Conclusion The use of HiperSockets can be highly recommended. By using HiperSockets, we were able to fully utilize the WebSphere Application Server, which, unfortunately, WebSphere Application Server Base Performance 21

26 limits the improvement. The fact that it is possible to increase the transaction throughput by modifying the network connection type indicates that the network connection between the WebSphere Application Server and the database needs a very high bandwidth. The WebSphere Application Server itself is not a bottleneck. WebSphere Application Server 6.1 (64-bit) Figure 17. ETR, ITR, and CPU utilization for the OSA card versus HiperSockets test case Observations The use of HiperSockets as a connection type between the WebSphere Application Server and the database leads to a large improvement of 33% in throughput and the CPU load increases by 43%, which leads to a decreasing ITR and a highly utilized system. Conclusion These results confirm that the connection between the WebSphere Application Server and the database requires a high bandwidth, which can only be delivered by HiperSockets. Overall conclusion for OSA card versus HiperSockets In general, the use of HiperSockets can be highly recommended. HiperSockets has much lower latencies because it is implemented in memory. This results in much higher network throughput, but it is completely driven by the CPs. This means it is also related to higher CPU cost because no work can be delegated to the OSA Express card. Systems running with fully utilized CPUs might not benefit from this change. 22 WebSphere Application Server Base Performance

27 Overall view - DB2 database on z/os Figure 18. Impact on throughput with the database on z/os Figure 18 shows the impact of the various changes for the environment with the database on z/os. The changes are cumulative to the right, meaning that the scenario labeled DB2 v9 also uses WebSphere Application Server 6.1, two OSA cards, and the new database layout. The chart shows that significant improvements in throughput (ETR and ITR) came when we: 1. Used WebSphere Application Server Divided the network streams from the WebSphere Application Server to the client and to the database 3. Optimized the database layout 4. Introduced HiperSockets connections to the database server Overall, we reached an improvement of about 70% even with the decrease in throughput seen with SLES10. WebSphere Application Server Base Performance 23

28 DB2 database on Linux Figure 19. Impact on throughput with the database on Linux Figure 19 shows the impact of the various changes for the environment with the database on Linux. The changes are cumulative to the right, meaning that the scenario labeled DB2 v9 also uses two OSA cards. All scenarios use WebSphere Application Server 6.1. Here we have less data points because we did not perform all runs with the database on Linux. The overall improvement here is much lower because the entry point 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 as impressively as with the database on z/os because the WebSphere Application Server was CPU constrained. 24 WebSphere Application Server Base Performance

29 Related information WebSphere Application Server performance tests - hardware and software configuration To perform our WebSphere Application Server tests, we created a customer-like environment. We configured the hardware, software, network, and storage server. WebSphere Application Server performance tests - system setup To emulate a customer-like environment we needed to setup our network, the WebSphere Studio Workload Simulator client, the database, and WebSphere Application Server. WebSphere Application Server performance tests - other sources of information Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. Other sources of information for the WebSphere Application Server performance tests Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and at various Web sites. For information on Linux on System z see: For information on WebSphere Application Server see: For information on IBM open source projects see: Redbooks from v WebSphere Application Server V6.1: Planning and Design v WebSphere Application Server V6.1: System Management and Configuration For information on the Trade 6.0 application, see the IBM Redbook Using WebSphere Extended Deployment V6.0 to Build an On Demand Production Environment at: It discusses Trade 6 installation. After installing the Trade 6, the Web application contains details on the Trade 6 application architecture and other information. For general instructions on installing and configuring the various components in the topology, see the IBM RedBook WebSphere Application Server V6 Scalability and Performance Handbook found at: For performance information for Trade on WebSphere Application Server see: WebSphere Application Server Base Performance 25

30 Notices for the WebSphere environment performance tests Additional resources to provide information on the products, hardware, and software discussed in this paper can be found in various books and various Web sites. 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 trademarks of International Business Machines Corporation of the United States, other countries 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 other countries. Intel and Xeon are trademarks of Intel Corporation in the United States, other countries or both. Linux is a registered trademark of Linus Torvalds in the United States and other countries. Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States, other countries, or both. Other company, product and service names may be trademarks or service marks of others. Information concerning non-ibm products was obtained from the suppliers of their products or their published announcements. Questions on the capabilities of the non-ibm products should be addressed with the suppliers. IBM hardware products are manufactured from new parts, or new and serviceable used parts. Regardless, our warranty terms apply. IBM may not offer the products, services or features discussed in this document in other countries, and the information may be subject to change without notice. Consult your local IBM business contact for information on the product or services available in your area. All statements regarding IBM s future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Performance is in Internal Throughput Rate (ITR) ratio based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput that any user will experience will vary depending upon considerations 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 achieve throughput improvements equivalent to the performance ratios stated here. 26 WebSphere Application Server Base Performance