Performance has never been as critical as it is
today. The compelling need to get the most out of our resources has led
Microsoft to improve the mechanisms available to conduct performance
testing and also performance tuning.
The concept of
measuring performance is very much like that of addressing security.
Performance has to be addressed in several layers. In mainframe
integration scenarios, you should start from the mainframe layer, and
then you can move to the Network layer, the Services layer, and finally
to the Application layer. The fact that every layer has its own
characteristics and constraints makes planning for thorough and
successful performance testing and tuning a required activity.
1. Performance Testing
When working
with Transaction Integrator, we recommend using the Microsoft Visual
Studio Test Edition. Although many tools are available for performance
testing, Microsoft Visual Studio Test Edition is the one tool that
integrates best with .NET servers. By using it, you can create test
scripts to stress your application. You can stress test TI objects
published as web services and as WCF services, and you can also test
their web consumer applications. To target BizTalk applications that
consume TI objects or that use the BizTalk Adapter for Host
Applications, you can also use LoadGen. Remember that the BAHA runtime
captures the data sent from the BizTalk Messagebox database and sends it
to the Transaction Integrator runtime. From there you can create your
own custom message creator implementing the IMessageCreator interface and generate as many input instances as you need.
1.1. Performance Counters
Once you decide which
approach you will follow to stress Transaction Integrator, then you have
to define which performance counters you will collect. Yes, you are
right; we're skipping the part of the service-level agreement (SLA)
definition because that will entirely depend on your architecture. Host
Integration Server includes numerous counters for the different roles
that can be deployed. The use of the Host Integrator performance
counters will allow you to capture critical data about multiple elements
of your solution, including variables such as the time that it takes a
transaction to go to the mainframe and back to the client application or
the time that applications like BizTalk Server take to call TI objects.
For instance, for the CICS link programming model, we recommend the following counters for the SNA Gateway server role:
SNA Connections: Throughput Bytes/Sec
SNA Logical Unit Sessions: Throughput Bytes/Sec
SNA Logical Unit Sessions: Data Bytes Received/Sec
SNA Logical Unit Sessions: Data Bytes Transmitted/Sec
SNA Adapter adaptername: Throughput Frames/Sec
SNA Adapter adaptername: Connection Failures
SNA Adapter adaptername: Successful Connects
And for the Transaction Integrator server role, we recommend the following:
App Integration WIP\Average method call time
App Integration WIP\Cumulative calls
App Integration WIP\Host resp time CICS link
App Integration WIP\Link calls/sec
App Integration WIP\Total errors/sec
App Integration WIP\Bytes received from an SNA host/sec
App Integration WIP\Bytes sent to an SNA host/sec
Ultimately, the selection of
the performance counters will depend on your specific needs. The list of
counters provided here is suggested for an architecture using TI
nodeless servers and SNA Gateway servers.
1.2. IBM RMF Monitor
One way to monitor
mainframe performance is through the use of the IBM RMF Monitor. It
performs post-processing and online monitoring functions. It is
accessible from TSO and among other things can monitor the VTAM address
space and performance relevant data in a z/OS environment.
Figure 1
shows the main options for RMF Monitor. For details on how to use it,
you can read the IBM Redbook entitled "SG24-7110-00 z/OS Diagnostic Data
Collection and Analysis."
2. Performance Tuning
There are a few
recommendations from a performance standpoint that we would like to
high-light. Some of them are also available at http://msdn.microsoft.com/en-us/library/aa745251.aspx.
2.1. APPC
The following recommendations apply when working with the APPC API and/or SNA aliases:
Pre-activate the LU 6.2 sessions:
This will prevent a short delay in establishing new LU 6.2 sessions.
Sometimes the mainframe preactivates the sessions, which may cause a
short delay in the Host Integration because the mainframe is actually
deciding when to serve the request.
Perform SNA link tuning:
This should be performed depending on the type of network used. For
IP-DLC, we recommend validating the advanced settings in the IP-DLC Link
Service with the mainframe team.
SNA load balancing: Although this is not a tuning activity, we recommend the use of APPC load balancing for fault tolerance and redundancy.
2.2. Transaction Integrator
The following performance improvement recommendations apply when working with Transaction Integrator:
Tune the Remote Application (Mainframe TP): This should be performed by the mainframe team.
If you are not using 2PC, configure the TI component as Does Not Support Transactions so that 2PC is not attempted:
The same applies for the BAHA configuration. Verify that the Use
Transactions property is set to No if you are not using transactions.
It is very important to tune the network:
Host Integration Server performance is very impacted by the number of
hops between the mainframe and it. If you cannot have the Host
Integration Server located in the same switch where the mainframe is
connected to, then try to minimize the number of hops between them.
Something additional you will have to analyze is whether the network
switches are set up to half-duplex or full-duplex. Work with the network
engineers to analyze Netmon traces and to troubleshoot any possible
bottleneck.
2.3. Session Integrator
For Session Integrator
transport, we recommend the use of the SNA transport (DLC or IP-DLC)
over TN3270 to maintain 100% reliability of the 3270 conversation.
2.4. BizTalk Adapter for Host Applications
From a performance
standpoint, we recommend you create a new send handler and configure the
HostApps adapter to use it. By doing this, you can set up the HostApps
adapter to run in a host instance other than the default
BizTalkServerApplication one. By doing that, you avoid having the
HostApps adapter in competition with resources designated for
orchestrations and other in-process resources. Likewise, if you have
more than one server available, you can create more host instances for
the HostApps adapter. Doing so will improve the BAHA throughput and also
will provide redundancy for your solution. Figure 2 shows a BizTalk Server solution with two BizTalk Servers hosting two BAHA host instances.
