Workload descriptions
As described in 2.1, “Workloads” on page 12, a workload is a collection of application programs (started by a simulated operator) where the application accesses data from one or more data stores.
This chapter describes several general-purpose workloads that are used by IBM to report performance results in every release of CICS TS for z/OS. It also highlights some of the functional areas that are covered by the test cases.
This chapter includes the following topics:
3.1 Regression testing
One of the primary objectives of testing the performance of the CICS TS product is to ensure that customer workloads do not observe a degradation in performance when upgrading to a new release. The process of comparing one release of CICS TS with another by using identical workloads and identical configurations is known as regression testing.
Each chapter in Part 2, “CICS TS performance information” on page 39 provides information that relates to a specific CICS TS release. A significant component of all the release-specific chapters are the results of running regression test workloads. For more information about the details of workload results, see Chapter 5, “CICS TS for z/OS V5.1” on page 41, Chapter 6, “CICS TS for z/OS V5.2” on page 77, and Chapter 7, “CICS TS for z/OS V5.3” on page 109.
|
Note: Not all results of every workload that is executed during the development phase of a CICS TS release are presented in the performance report.
|
Many workloads are used during regression test. The remainder of this chapter outlines some of the workloads that are available to the CICS TS performance team in the IBM development organization.
3.2 Data Systems Workload
The Data Systems Workload (DSW) is a non-threadsafe COBOL application that accesses VSAM files. Transactions use Basic Mapping Support (BMS) maps to interface with 3270 terminals. The amount of files in use varies depending on configuration, but can be in the range of 16 - 320.
The DSW workload is composed of a number of transactions, where 50% of CICS transactions issue at least one file control (FC) request. On average, six FC requests are issued per CICS task. FC requests are distributed in the following percentages:
•69% read
•10% read for update
•9% update
•11% add
•1% delete
To simulate users of the application in a controlled manner, IBM Workload Simulator for z/OS is configured to emulate many 3270 terminals. Depending on the configuration, the amount of simulated users can be in the range of 1,000 - 4,000.
Several configuration options are available for DSW. Some of these variants are described in the following sections.
3.2.1 DSW static routing
Five CICS regions are configured for the workload. Two terminal-owning regions (TOR) connect to two application-owning regions (AOR). These two AORs then connect to a file-owning region (FOR). Files are accessed in the FOR by using VSAM local shared resources (LSR).
Work enters the system in a TOR and is then transaction-routed to the corresponding AOR. The business logic of the workload then accesses the VSAM data by using CICS function shipping to the FOR. Temporary storage (TS) requests are fulfilled by using local, unrecoverable, auxiliary temporary storage.
All connections use the multi-region operation and cross-memory (MRO/XM) protocol. CICSplex System Manager is not used to provide dynamic workload routing in this scenario. Figure 3-1 shows the topology of DSW in a static routing configuration.
Figure 3-1 Topology of the DSW performance workload in static routing configuration
3.2.2 DSW dynamic routing
By using the same business logic and file structure as the static routing variant of the DSW, the application is extended to include the use of VSAM record-level sharing (RLS) and CICSplex System Manager (CICSPlex SM) dynamic transaction routing. The use of CICSplex SM introduces the requirement for the following two CICS regions:
•CICSPlex SM address space (CMAS) region
The CMAS region is the component of the CICSplex SM topology responsible for most of the work that is involved in managing and reporting on CICS regions and their resources. Each CICSplex must have at least one CMAS.
•Web user interface (WUI) server
The WUI server is a CICS region that acts as a CICSPlex SM application, which uses the API to view and manage objects in the data repositories of CICSPlex SM address spaces.
To remove application affinities and enable dynamic workload distribution, temporary storage requests are fulfilled by using shared temporary storage, which is held in the coupling facility (CF).
As with the static routing configuration, all connections between CICS regions use the MRO/XM protocol.
Transactions enter the system through TORs by using the BMS maps interface, and are then transaction-routed to an AOR. Although the static routing variant that is described in 3.2.1, “DSW static routing” on page 22 is connected to a single AOR only, all TORs are connected to all AORs in this scenario. A CICSPlex SM workload is defined and installed to route transactions dynamically from the routing regions (the TORs) into the target regions (the AORs). File commands from the business logic use the support for VSAM RLS in CICS TS to access the required data.
Typically, a dynamic routing configuration uses four TORs and 30 AORs, although not all regions are highlighted in topology diagrams. Figure 3-2 shows the topology of the DSW workload when it is configured to use dynamic routing with CICSPlex System Manager.
Figure 3-2 Topology of the DSW performance workload in dynamic routing configuration
3.2.3 DSW dynamic routing by using IPIC
The topology of this workload is the same as described in 3.2.2, “DSW dynamic routing” on page 23. The only difference between these variants is that IP interconnectivity (IPIC) is used to facilitate communication between CICS regions, rather than the MRO/XM protocol.
As described in 2.2, “Workload design” on page 12, workloads are designed to minimize any unnecessary overhead or variations in runtime performance. The DSW IPIC workload uses the TCP/IP home address (127.0.0.1) to avoid testing physical networking hardware.
3.3 Relational Transactional Workload
The Relational Transactional Workload (RTW) is a COBOL application that accesses a DB2 database. Transactions use BMS maps to interface with 3270 terminals.
Seven transaction types access 16 DB2 tables by using EXEC SQL commands. In total, slightly more than 30 million rows of data are defined in the database. On average, each CICS task issues 200 DB2 SQL calls. These SQL requests are distributed in the following percentages:
•54% SELECT
•1% INSERT
•1% UPDATE
•1% DELETE
•8% OPEN CURSOR
•27% FETCH CURSOR
•8% CLOSE CURSOR
The two main variants of the RTW workload are non-threadsafe and threadsafe.
The non-threadsafe variant of RTW includes all PROGRAM resources defined with the CONCURRENCY attribute set to the value of QUASIRENT.
The threadsafe variant specifies the value of REQUIRED. For more information about the effects of this variation, see Chapter 4, “Open transaction environment” on page 31.
Typically, the RTW workload is executed as a stand-alone CICS region, but some test scenarios require many transactions. To achieve high transaction rates, a variant of the RTW workload is available and uses TORs and AORs in a similar manner that was described for DSW in 3.2.2, “DSW dynamic routing” on page 23. Figure 3-3 shows the topology of the RTW workload in a high-volume configuration.
Figure 3-3 Topology of high-volume RTW configuration
3.4 WebSphere Liberty servlet with JDBC and JCICS access
The workload that is presented in this section is a pure Java application, based on the CICS-supplied JDBC sample application. For more information about the sample JDBC servlet application, see the “About the servlet examples” topic in IBM Knowledge Center, which is available at this website:
The sample application is composed of a Java servlet, which accesses an SQL database by using the Java JDBC API and the IBM Data Server Driver for JDBC with type 2 connectivity. The values that are retrieved from the database are then rendered as an HTML page and sent to the client as the response. For this workload, the sample application was expanded to also access a VSAM file by using the JCICS interface. The VSAM file contains a copy of the data that is held in the sample database.
The supplied sample application uses the CICSDB2DynamicSQLExample.getData(String) method to read 42 rows from the sample DB2 table EMP. This method was modified to also read 42 records from a VSAM file by using JCICS KeyedFileBrowse.next() calls and display the data as extra entries in the HTML table that is returned to the client.
The application is deployed into a WebSphere Liberty environment inside a CICS JVM server. Simulated browser requests are made to the HTTP port that is specified in the server.xml configuration file. Figure 3-4 shows an overview of the application topology.
Figure 3-4 Topology of JDBC and VSAM servlet workload
The WebSphere Liberty server configuration file server.xml was automatically generated by specifying the following options in the JVM profile file for the JVM server:
•-Dcom.ibm.cics.jvmserver.wlp.autoconfigure=true
•-Dcom.ibm.cics.jvmserver.wlp.server.host=hostname
•-Dcom.ibm.cics.jvmserver.wlp.server.name=serverName
•-Dcom.ibm.cics.jvmserver.wlp.server.http.port=httpPort
The following entry was also added to the JVM profile configuration file to optimize retrieval of static resources from the web application:
-Dcom.ibm.cics.jvmserver.wlp.optimize.static.resources=true
By using IBM Workload Simulator for z/OS, 200 HTTP clients were simulated to provide a controlled rate of transactions in the CICS region under test. The workload measured overall central processor usage and zIIP usage of the address space.
3.5 Java OSGi workload
The Java OSGi workload is composed of several applications. This mixture includes some of the JCICS sample applications as described in the “The JCICS example programs” topic in IBM Knowledge Center at this website:
The CICS BUNDLE JDBC example, “Hello World,” and temporary storage queue (TSQ) example were modified to include Java programming to simulate extra business logic, such as creating and manipulating strings, generating random numbers, and performing mathematical operations on these numbers.
The workload is driven by running CICS transactions at a simulated console by using IBM Workload Simulator for z/OS, as described in 2.4, “Driving the workload” on page 16.
Figure 3-5 shows an overview of the workload.
Figure 3-5 Overview of OSGi Java workload
3.6 Web services
The web services set of workloads measure the performance of CICS as a SOAP web service provider. These workloads contain a range of configuration options for testing, including variations of:
•Connection persistence
•SSL usage
•SSL provider
•SSL handshake type (none, partial, or full)
All variations follow the same application topology, as shown in Figure 3-6. Notice that other resources are required to configure CICS to use web services, but these have been omitted for clarity. For a detailed setup guide, see the “Configuring web services in CICS” topic in IBM Knowledge Center at this website:
Figure 3-6 Topology of CICS web services workload
The DFHLS2WS utility is used to produce a CICS wsbind file. This file is installed into the CICS provider region and configures CICS to invoke a COBOL application using a channel interface.
Two copybooks are used as input to the utility:
•The first copybook defines the input data to the SOAP web service.
•The second copybook defines the output data from the SOAP web service.
Both copybooks are similar, with the input data copybook shown in Example 3-1. This configuration results in a web service that accepts a SOAP message that contains 10 80-byte fields as an input and returns a SOAP message that contains 10 80-byte fields as an output.
Example 3-1 Copybook used for input data to SOAP web service
01 RECEIVED-DATASTRUCTURE.
02 JB1 PIC X(80).
02 JB2 PIC X(80).
02 JB3 PIC X(80).
02 JB4 PIC X(80).
02 JB5 PIC X(80).
02 JB6 PIC X(80).
02 JB7 PIC X(80).
02 JB8 PIC X(80).
02 JB9 PIC X(80).
02 JB10 PIC X(80).
The workload is driven using a second CICS region (the requester region) using a URIMAP resource to send web service requests into the CICS provider region under test. The requester region runs on a separate LPAR and is driven by running CICS transactions at a simulated console by using IBM Workload Simulator for z/OS, as described in 2.4, “Driving the workload” on page 16.
The CPU consumption of the CICS provider region is measured during execution of the benchmark. When combined with the known arrival rate of the SOAP messages, a CPU per request value can be obtained.
3.6.1 Web services variations
Test variations are achieved by modification of resources in both the provider and requester regions, with the following available options:
•Connection persistence
The choice between persistent and non-persistent connections is configured by modifying the SOCKETCLOSE attribute in the URIMAP of the requester region. When set to zero, the connection closes after the response message arrives.
•Use of SSL
SSL is enabled by specifying the SCHEME(HTTPS) parameter in the URIMAP of the requester region.
•Use of CICS SSL or AT-TLS
The use of CICS SSL is configured by specifying SSL(YES) for the TCPIPSERVICE parameter in the provider region. The use of Application Transparent Transport Layer Security (AT-TLS) is achieved by specifying SSL(NO) for the TCPIPSERVICE parameter in the provider region and configuring AT-TLS in IBM Communication Server.
•SSL handshake type
No SSL handshakes are performed during the measurement period when persistent connections are used; the configuration of this is described previously. When non-persistent connections are used, the CICS SSLDELAY SIT parameter in the requester region controls whether a full or a partial SSL handshake is performed.
A setting of zero for SSLDELAY specifies that the provider region will not cache SSL session tokens, and therefore a full SSL handshake will take place for every new connection.
A non-zero setting for SSLDELAY specifies the amount of time in seconds for which the provider region will cache the SSL session token. A value of 600 is used to guarantee the session token is always cached between successive requests, regardless of the transaction rate used.
3.7 File control workload
The DSW application described in 3.2, “Data Systems Workload” on page 22 predominantly exercises the CICS File Control interface, however the application is not threadsafe. As described in 9.3, “Improvements in threadsafety” on page 206 the CICS TS V5.5 release introduced the ability to access Coupling Facility Data Tables (CFDTs) from an Open TCB. Testing this functionality required a new threadsafe workload to exercise the CICS File Control API. This section describes the generic threadsafe File Control workload that can be configured for several different scenarios.
All programs in the application are written using threadsafe programming practices. Three main programs are used, with the following purpose:
•Terminal handling program
This program reads and validates input from the 3270 terminal. The input is used to specify several configuration options. These configuration options are stored in a channel and passed to the TCB switch program using EXEC CICS LINK.
Specifies QUASIRENT for the CONCURRENCY attribute.
•TCB switch program
This program accepts configuration from the terminal handling program and then passes this configuration unchanged to the main application logic program using EXEC CICS LINK. The TCB switch program is used only to ensure the main application logic program begins execution on the correct TCB.
When binding the TCB switch program, the binder produces two aliases and both aliases are defined as PROGRAM resources in the CICS region. Each program definition specifies a different value for the CONCURRENCY attribute. The terminal handling program can select which TCB that the main application program should use, simply by selecting the correct program alias. For more details on TCB switching in CICS, see Chapter 4, “Open transaction environment” on page 31.
Specifies QUASIRENT (non-threadsafe configuration) or REQUIRED (threadsafe configuration) for the CONCURRENCY attribute.
•Main application logic program
This program accepts the supplied configuration and translates this into the requested combination of CICS File Control calls.
Specifies THREADSAFE for the CONCURRENCY attribute.
A minimum of two and a maximum of 1,000 VSAM KSDS files can be defined in the application. Each file can be defined to have one of three record lengths: 64 bytes, 100 bytes, or 256 bytes.
Each transaction accesses a number of records, which is specified by the data supplied at the terminal. A read-only transaction performs one EXEC CICS READ command per record. An update transaction performs one EXEC CICS READ UPDATE and one EXEC CICS REWRITE command per record. All file reads compute a hash value to validate data integrity.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.