Host Integration Server 2006 TI Performance

MicrosoftHost Integration Server 2006
Transaction Integrator Performance White Paper
Published: February 2008

Table of Contents
INTRODUCTION...............................................................................................................................4
EXECUTIVE SUMMARY AND RESULTS...................................................................................................6
TI PERFORMANCE LAB OVERVIEW.......................................................................................................7
HOST EMULATOR SERVER...................................................................................................................7

TI / HIS / BIZTALK 2006 SERVER............................................................................................................7
TI PERFORMANCE LAB TEST CASES......................................................................................................8
BIZTALK TESTS...................................................................................................................................8
ELM TESTS.......................................................................................................................................9
TRM TESTS....................................................................................................................................10
IMS TESTS.....................................................................................................................................10
IIS TESTS....................................................................................................................................... 10
GENERAL TI SERVER PERFORMANCE TUNING.......................................................................................11
TI PERFORMANCE ELEMENTS.................................................................................................................11
Host Internal Response Time..........................................................................................................11
External Computer Response Time...................................................................................................12
Network Delay.............................................................................................................................12
True User Response Time...............................................................................................................12
SNA Communications Elements...................................................................................................16
WINDOWS SERVER 2003 TUNING............................................................................................................18
Adjusting Application Priority.........................................................................................................18
Reducing Context Switching...........................................................................................................18
Streamlining Authentication...........................................................................................................19
Optimizing Network Throughput.....................................................................................................19
IIS 6.0 SERVER TUNING.......................................................................................................................20
Connections................................................................................................................................20
Connection timeout......................................................................................................................20
HTTP Keep-Alives.........................................................................................................................20
Logging......................................................................................................................................20
Bandwidth throttling.....................................................................................................................21
Web Site Connections....................................................................................................................21
ISAPI Filters.................................................................................................................................21
Application Configuration..............................................................................................................22
Session State...............................................................................................................................22
Buffering....................................................................................................................................22
Parent Path, Default ASP Language, and ASP Script Time-Out...............................................................23
© Microsoft Corp. 2008

ASP server-side script and client-side script debugging........................................................................23
Cached limited ASP Files in memory.................................................................................................23
Cached limited ASP Files on disk......................................................................................................24
IIS 5 Isolation Mode......................................................................................................................24
HTTP compression........................................................................................................................24
Application Pool Recommendations.................................................................................................25
Memory Recycling........................................................................................................................25
Maximum virtual memory (in megabytes):........................................................................................25
Maximum used memory (in megabytes):..........................................................................................25
Idle timeout................................................................................................................................25
Request Queue Limit.....................................................................................................................26
CPU Monitoring...........................................................................................................................26
Web Garden................................................................................................................................26
Pinging.......................................................................................................................................27
Rapid fail protection.....................................................................................................................27
Startup time limit.........................................................................................................................27
Shutdown time limit.....................................................................................................................27
ADDITIONAL TECHNICAL RESOURCES.................................................................................................28
APPENDIX I: TEST PARAMETERS........................................................................................................29
ELM LINK DIRECT CALL HEAVY CONVERSION..................................................................................................29

ELM LINK DIRECT CALL MEDIUM CONVERSION..............................................................................................30
ELM LINK DIRECT CALL MEDIUM CONVERSION WITH 500MS OF HOST UOW TIME......................................................32
ELM LINK DIRECT CALL MEDIUM CONVERSION WITH RE OVERRIDE.......................................................................33
ELM LINK DIRECT CALL MEDIUM CONVERSION 2PC........................................................................................34
IMS CONNECT MEDIUM CONVERSION........................................................................................................35
IMS CONNECT MEDIUM CONVERSION 2PC..................................................................................................36
ELM LINK DIRECT CALL LIGHT CONVERSION.................................................................................................37
ELM LINK DIRECT CALL LIGHT + UDTS......................................................................................................38
ELM LINK DIRECT CALL LIGHT + DATA SET..................................................................................................39
IIS + ELM LINK TI WEB SERVICES (DATA SETS)............................................................................................40
IIS + ELM LINK .NET REMOTING (DATA TABLES)..........................................................................................41
ELM LINK WITH PERSISTENT CONNECTION MEDIUM CONVERSATION......................................................................42
ELM LINK WITH PERSISTENT CONNECTION MEDIUM CONVERSATION 2PC................................................................43
TRM LINK DIRECT CALL MEDIUM CONVERSATION...........................................................................................44
IIS + ELM LINK TI WEB SERVICES MEDIUM CONVERSION..................................................................................45

MicrosoftHost Integration Server 2006 Transaction Integrator
Performance White Paper
Published: February 2008
Introduction
This White Paper offers information and performance metrics regarding the Transaction Integrator (TI)
capabilities provided by Microsoft® Host Integration Server 2006 (HIS 2006). These components enable
application integration of host-based systems with applications based on the Microsoft .NET Framework.
Specifically, TI enables synchronous integration with mainframe-based transaction programs (TP) and
AS/400 transactions.
With TI, you can integrate existing mainframe or midrange programs with Microsoft Windows®-based
applications built on the .NET Framework or COM+/DCOM components. Additionally, companies usually
can deploy TI without having to modify their host programs (assuming the program or TP has separated
business and presentation logic).
This allows companies to preserve existing investments in zSeries and iSeries programs (COBOL, RPG,
etc.), while also extending these programs to a three-tier client/server or Web-to-host computing
environment. Furthermore, this enables you to expose these applications using common Microsoft
development tools and technologies — such as Microsoft Visual Studio®, Microsoft Expression®, and
Microsoft Silverlight™.
TI supports both SNA connectivity and TCP/IP connectivity without requiring any new host code or host
transaction rewrites.
True integration of online transaction processing (OLTP) with .NET or COM-compliant systems can be
defined as the integration of zSeries and iSeries with Windows-based solutions. TI integrates OLTP with
these systems by creating .NET or COM interfaces to the transactions and then running the host
transactions on the mainframe from Windows. Initiating host programs from Windows is referred to as
Windows Initiated Processing, or WIP. Likewise, host programs can call into Windows-distributed
applications, a process known as Host Initiated Processing, or HIP. Furthermore, both WIP and HIP can
leverage batch-processing calls to accommodate the typical nightly processing on host systems.
Additionally, TI 2006 provides a BizTalk Adapter for Host Applications. This adapter allows companies to
extend host programs with new solutions based on Microsoft BizTalk® Server 2006 and while working in
Microsoft Visual Studio 2005.
All hardware in the testing was conducted on servers equipped with Dual-Core AMD Opteron 2220 SE
processors provided by Advanced Micro Devices (www.amd.com).
Page 4 of 50
http://www.microsoft.com/hiserver
While Transaction Integrator offers various call capabilities to host systems, the focus of this White
Paper covers TCP/IP WIP (non-2PC) transactions.
Specifically, the tests included varying configurations and data conversations for the following calls:
 BizTalk Adapter for Host Systems

 ELM LINK Direct Calls
 ELM LINK with Persistent Connections
 IIS + ELM Link TI Web Services
 IIS + ELM Link .NET Remoting
 TRM LINK Direct Calls
 IMS Connect Calls
This White Paper details the performance tests performed by the Microsoft Host Integration Server
Product Group and Microsoft Gold Certified Partner The Henson Group (www.HensonGroup.com). Tests
were conducted at Microsoft’s Redmond headquarters using two internally developed performance
testing tools known as the Managed Performance Client for .NET WIP Programming Models and TI
Performance Host for IBM CICS, IMS and OS-400.
When reviewing this material, consider that Microsoft and The Henson Group (THG) based the testing
scenarios and recommendations on applicable field work. HIS 2006 specialists and users are encouraged
to engage with Microsoft — including participation in forums for discussion and learning — to meet
their informational needs, both during deployment initiatives and for the future.
If further clarification is required, please contact THG at [email protected] or contact your

Microsoft Account Executive to access Microsoft’s HIS 2006 product group.
For the latest information on Microsoft Host Integration Server 2006 technology, visit
http://www.microsoft.com/hiserver.
Page 5 of 50
Executive Summary and Results
Respectable mainframe transaction throughput numbers range from approximately 220 transactions
per second (TPS) to 350 TPS on a single host. (The IBM cluster (parallel sysplex) claims high throughput
rates of 770 TPS.)
Microsoft Host Integration Server 2006 (HIS 2006) offers faster transaction response times for .NET
Transaction Integrator (.NET TI), compared to previously published statistics of its predecessors. While
the BizTalk Adapter for Host Applications was not offered in previous versions, the test results for this
adapter are impressive, based on transactional throughput. It can be concluded that HIS 2006 TI can
benefit any organization looking to leverage .NET TI as an enterprise-level integration solution.
The following table displays a summary of the data collected, with a brief description of the test. These
tests and specific data regarding their implementation and relevance are detailed later in this White
Paper.
Host Integration Server Transaction Integrator 2006

on a Dual-Core AMD Opteron Processor 2220 SE 2.81 GHz
Transaction Size Throughput Response Time
(485-509 bytes in/out) (TPS) (ms)
BizTalk Adapter for Host Applications No Conversion – Non-Persistent Connection 140.58 N/A
BizTalk Adapter for Host Applications Heavy Conversion – Non-Persistent Connection 120.93 N/A
BizTalk Adapter for Host Applications Medium Conversion - Non-Persistent Connection 115.21 N/A
BizTalk Adapter for Host Applications Light Conversion - Non-Persistent Connection 126.42 N/A
BizTalk Adapter for Host Applications No Conversion – Persistent Connection 134.80 N/A
BizTalk Adapter for Host Applications Heavy Conversion – Persistent Connection 117.27 N/A
BizTalk Adapter for Host Applications Medium Conversion - Persistent Connection 117.62 N/A
BizTalk Adapter for Host Applications Light Conversion - Persistent Connection 133.37 N/A
ELM Link Direct Call Heavy Conversion 798 35
ELM Link Direct Call Medium Conversion 1288 22
ELM Link Direct Call Medium Conversion with 500ms of host UOW time 65 499
ELM Link Direct Call medium conversion with RE Override 1258 23
ELM ink Direct Call Medium conversion 2PC 1272 23
ELM Link Direct Call Light conversion 1488 20
ELM Link Direct Call Light + UDTs 1199 24
ELM Link Direct Call Light + Data Set 926 31
ELM Link with Persistent Connection Medium conversion 1419 21
ELM Link with Persistent Connection Medium conversion 2PC 1414 20
TRM Link Direct Call Medium conversion 1270 23
IMS Connect medium conversion 1217 23
IMS Connect medium conversion 2 PC 1185 25
IIS + ELM Link TI Web Service medium conversion 687 45
IIS + ELM Link TI Web Service (Data Sets) 664 47
Page 6 of 50
IIS + ELM Link .NET Remoting (Data Tables) 442 69
TI Performance Lab Overview

Microsoft and The Henson Group built a lab comprising of two Dual-Core AMD Opteron 2220 SE servers.
HOST EMULATOR SERVER

CPU 1: Dual-Core AMD Opteron Processor 2220 SE 2.81 GHz
RAM: 7.87 GB
Hard Drives:
Disk 0, 7,200 rpm, 300 GB, SATA raid
Volume C: 152,664 MB
Volume D: 152,578 MB
OS: Windows Server® 2003 Enterprise x64 Edition with Service Pack 2
TI / HIS / BizTalk 2006 SERVER

RAM: 7.87 GB
Hard Drives:
Disk 0, 7,200 rpm, 300 GB, SATA raid
Volume C: 152,664 MB
Volume D: 152,578 MB
OS: Windows Server 2003 Enterprise x64 Edition with Service Pack 2
Page 7 of 50
1) Method Call 2) Request and Data
Send to Host
Application entity
Host
TI 2006
Emulator
HIS 2006
BizTalk 2006
IIS 2006
4) Return Data 3) Replay and Data
Send from Host
TI Performance Lab Test Cases

BizTalk Tests
The Microsoft BizTalk Adapter for Host Applications is based on technology in Transaction Integrator (TI)
that enables enterprises to connect BizTalk Server solutions to existing IBM mainframe zSeries (CICS and
IMS) or midrange iSeries (RPG) server programs. The adapter offers an intuitive Visual Studio 2005
designer, including host COBOL and RPG source code import wizards, with which to generate XSD
schemas for use in BizTalk projects. The administration tools are integrated with the BizTalk Server port
configuration and deployment tools. Using this adapter, IT professionals can efficiently extend existing
business rules in host programs with new solutions based on BizTalk Server 2006.
A typical scenario involves the following steps:
 The IT professional installs the adapter.
 The IT professional configures the adapter and uses Transaction Integrator to define the Remote
Environment.
 The developer creates the BizTalk application in Visual Studio. This involves:
o Defining the Remote Environment

o Building the TI Assembly and Schema
o Deploying, Testing, and Debugging the Application
o Exporting the Assemblies and the Remote Environment information
o Building the Export Package for Use by BizTalk Server.
 Finally, the IT professional imports the developer’s application into BizTalk Server, updates
necessary information, and deploys the application.
The BizTalk testing that was conducted tested the performance for the Microsoft BizTalk Adapter for
Host Applications. The test scenario involved the following setup in BizTalk Server: a File Receive Port, to
which a TI send port subscribes.
The file receive port reads the xml docs from a receive location on disk and BizTalk Server passes the
data to the TI adapter. Depending on the content of these XML files, TI knows what programs to call on
Page 8 of 50
the simulated host. The return value of the TI call is then passed to a File Send port that is subscribed to
our TI send port, which then writes it out to disk.
Performance testing was done using a load generation tool that continuously dumped the request XML
docs into the file receive location, generating the load needed, and observing the TI performance
counters in Windows Performance Monitor to get throughput numbers.
The TI functions that were called during the tests were the no conversion, light, medium, and heavy
conversion functions. The tests were run over the ELM Link programming model, and were run with
both persistent and non-persistent connections
The programming models implored during the test of the BizTalk Adapter for Host Applications included
the following:
 BizTalk Adapter for Host Applications No Conversion – Non-Persistent Connection

 BizTalk Adapter for Host Applications Heavy Conversion – Non-Persistent Connection
 BizTalk Adapter for Host Applications Medium Conversion - Non-Persistent Connection
 BizTalk Adapter for Host Applications Light Conversion - Non-Persistent Connection
 BizTalk Adapter for Host Applications No Conversion – Persistent Connection
 BizTalk Adapter for Host Applications Heavy Conversion – Persistent Connection
 BizTalk Adapter for Host Applications Medium Conversion - Persistent Connection
 BizTalk Adapter for Host Applications Light Conversion - Persistent Connection
ELM Tests
The TCP enhanced listener message (ELM) Link model allows data and parameters to be passed between
TI and the server TP using the COMMAREA. The model also allows a Concurrent Server to link to a CICS
DPL program. The enhanced Listener was introduced in CICS Transaction Server version 1.4 and its
architecture increases the efficiency of the CICS TCP/IP environment by eliminating the TRM and TRM
Reply sequence. The enhanced Listener accepts a header and requests data from the client in the initial
stream and eliminates the need for the server application to deliver a separate response before the
application data is made available. The enhanced Listener requires the client to:
 Construct and send a single data stream composed of a request header followed by the
application request data to the server application program
 Receive a single data stream that consists of a reply header and application data from the server
application program
The programming models implored during the ELM test included the following:
 ELM Link Direct Call Heavy Conversion

 ELM Link Direct Call Medium Conversion
 ELM Link Direct Call Medium Conversion with 500ms of host UOW time
 ELM Link Direct Call medium conversion with RE Override
 ELM ink Direct Call Medium conversion simulated 2PC
Page 9 of 50
 ELM Link Direct Call Light conversion
 ELM Link Direct Call Light + UDTs
 ELM Link Direct Call Light + Data Set
 ELM Link with Persistent Connection Medium conversion
 ELM Link with Persistent Connection Medium conversion simulated 2PC
TRM Tests
The TCP transaction request message (TRM) User Data programming model allows data and parameters
to be exchanged directly between TI and the host TP. The TCP TRM User Data model is based on the
CICS Concurrent Server model. The standard Listener uses two network exchanges to execute a single
transaction program.
The programming model implored during the TRM test included the following:
 TRM Link Direct Call medium conversation
IMS Tests
The IMS Connect programming model provides access to information management systems (IMS)
transactions using TCP/IP. This model uses the message queue for processing data.
The programming models implored during the IMS tests included the following:
 IMS Connect medium conversion

 IMS Connect medium conversion simulated 2PC
IIS Tests
A common approach to host integration is to leverage a Service-oriented Architecture (SOA) approach
leveraging web services or remoting.
The programming models implored during the Internet Information Services (IIS) tests included the
following:
 IIS + ELM Link TI Web Service medium conversation

 IIS + ELM Link TI Web Service (Data Sets)
 IIS + ELM Link .NET Remoting (Data Tables)

Page 10 of 50
Page 11 of 50
General TI Server Performance Tuning
TI Performance Elements
When performing your own tests or evaluating the performance of an existing TI implementation,
consider that several factors contribute to the total user response time, often called the response time
budget. To analyze the total system response time more easily, divide the response time into the parts
of the system that play a major role in the total response time budget. The following figure shows the
main divisions.
Three main divisions -- host, application server, and client --showing how response time is affected by at
least three levels within each division and by the network response time between divisions.
Windows Server 2003 Central Location – Data Center
Smart Client z/OS

ASP.NET Worker Process
CICS
Service Proxy
CICS EXEC
Account
Meta data Assembly Enterpris Inter-System CICS
Communications Lookup
e SSO LINK
Device TI Runtime
SNA LU6.2 TCP/IP VSAM
RACF Security Authentication

`
Desktop
Internet Host Integration

Information Server 2006
Services
IBM zSeries
Mainframe
When you are benchmarking the interactive performance of computers executing a transaction program
(TP) on the host, several response time and resource figures are of primary value. These include the host
internal response time, external computer response time, network delays, and the true user response
time, CPU use, and transaction rates.
Host Internal Response Time

The host internal response time is the time that the transactions spend inside the host system
processing the transaction requests from Transaction Integrator (TI). These include components such as
processing the business logic, disk and database I/O, and handling the two-phase commit (2PC)
processing.
One way to get an indication of the host internal transaction processing performance is to run the
transactions under load without the TI and computer components. A typical goal for an interactive
Page 12 of 50
transaction is to keep the response time at 500ms and less than one second for most part of the daily
load conditions.
External Computer Response Time

External computer response time is sometimes referred to as end-user response time or end-to-end
response time. It is the actual response time that the client application that is running on the computer
sees.
When you are using the "FAT-client" architecture, it includes all processing and network delays incurred
to the transaction from the time the call was sent to the TI server until the time the reply for the
transaction comes back. For "THIN-client" application architecture, additional delays are incurred
because of Internet Information Services (IIS).
Network Delay
Network delay is the difference between what the host measures as the internal transaction response
time and what the client computer sees as external response time, excluding the processing time on the
application server. On a high-speed local area network (LAN) deployment, the contribution from the
network delay can be very small, but when wide area networks (WAN), satellite hops, or modems are
involved, they can be major contributors to poor end-user response times.
True User Response Time

The true user response time is the time that the whole transaction takes to process. This is measured on
the user-interface level. The difference in the true user response time and the external computer
response time for Transaction Integrator (TI) transactions depends on how much of the processing is
done on the client itself. For the FAT-client approach, the opportunities to have "business logic" on the
client side are greater than that of the THIN-client. The THIN-client processing typically involves just
screen presentation processing delays.
The response time for FAT-client transactions through TI, when the host processing time is virtually zero,
is at maximum approximately 50 milliseconds for a small transaction (481 KB in/out). This is measured
by the Managed Performance for .NET WIP client application, and represents very closely the true end-
user response time, missing only the screen presentation processing time. The amount of data
conversion, heavy or light, and also using REOveride and UDTs did not affect the response time.
This response time includes the LAN delays for both TI processing and the backend host simulation
processing; it is as close as possible to the optimum possible performance.
On a properly tuned system, TI processing generally contributes less than 50 ms to the overall user
response time. Two-phase commit (2PC) adds approximately 100 ms to this as a result of the disk I/O for
the Microsoft Distributed Transaction Coordinator (DTC) logging.
The most significant contributor to the overall response time is naturally the host, where most of the
work is done (business logic and database access). So the area to focus first in optimizing the
performance is the host. To get a better idea of the response time and transaction volumes, use the
following 24 TI performance counters.
Active Clients
Page 13 of 50
Displays the total number of active clients, which are those clients that have created an instance of a TI
object, but have not yet released that instance.
Average method call time

Measures the average number of seconds of elapsed time that TI uses to process method calls made by
the client application. The time begins when TI receives the request from the client application (the
Invoke call). The time ends when TI returns control to the client application. This counter includes the
host response time, and it is not specific to any TI programming model. Consider the following two facts
when you are using this counter:
 Special TI properties, such as GetNewRecordsSet, have been omitted from the calculation.
 Two-phase commit (2PC) response time is not considered and is omitted from the calculation.
Bytes recv'd from a TCP host / sec

Displays the number of bytes per second received from the mainframe by TI over the TCP/IP protocol.
This counter is not specific to any TI TCP/IP programming model. For the CICS MSLink model, the
number reported will be slightly more than the amount of user data, due to the Link model protocol
header data. Bytes received from the host represent all data traffic, including user data.
Bytes recv'd from an SNA host / sec

Displays the number of bytes per second received from the mainframe by TI over the SNA protocol
(APPC/LU 6.2). This counter is not specific to any TI SNA (APPC/LU 6.2) programming model. For the CICS
Link model, the number reported will be slightly more than the amount of user data, due to Link model
protocol header data. Bytes received from the host represent all data traffic, including user data and
two-phase commit (2PC) flows.
Bytes sent to a TCP host / sec

Displays the number of bytes per second sent from TI to the mainframe over the TCP/IP protocol. This
counter is not specific to any TI TCP programming model. For the CICS MS Link model, the number
reported will be slightly more than the amount of user data, due to Link model protocol header data.
Bytes sent to the host represent all data traffic over TCP/IP, including user data.
Bytes sent to an SNA host / sec

Displays the number of bytes per second sent from TI to the mainframe over the SNA (APPC/LU 6.2)
protocol. This counter is not specific to any TI SNA (APPC/LU 6.2) programming model. For the CICS Link
model, the number reported will be slightly more than the amount of user data, due to Link model
protocol header data. This number is represented in terms of bytes per second.
Calls currently executing

Displays the number of method calls that are currently being executed.
Cumulative calls
Displays the total number of method calls that have occurred since the COM+ application was started.
Host resp time CICS Link

Measures the average time the host spends processing the transaction program's unit of work when the
CICS Link model is in use. In other words, this counter measures how long the host takes to respond to a
Page 14 of 50
request. The time starts after TI sends the final data buffer and ends when the first response buffer is
received by TI. This counter is represented in terms of seconds of elapsed time. Consider the following
two factors when you are using this counter:
 Multiple receives might be contained in the first response buffer sent to TI. Therefore, the
response time ends when TI has obtained all receives to the first response buffer.
Host resp time CICS Non-link or IMS

Measures the average time the host spends processing the transaction program's unit of work when
either the CICS Non-LINK or IMS models are in use. In other words, this counter measures how long the
host takes to respond to a request. The time starts after TI sends the final data buffer and ends when the
first response buffer is received by TI. This counter is represented in terms of seconds of elapsed time.
Consider the following two factors when you are using this counter:
 Multiple receives might be contained in the first response buffer sent to TI. Therefore, the
response time ends when TI has obtained all receives to the first response buffer.
Host resp time TCP Concurrent Server

Measures the average time the host spends processing the transaction programs unit of work when the
TCP/IP CICS Concurrent Server model is being used. This average time counter measures the time the
host takes to respond to a request sent to it. The time starts after TI sends the final data buffer and ends
when the first response buffer is received by TI. This counter is represented in terms of seconds of
elapsed time.
Host resp time TCP MS Link

TCP/IP CICS MSLink model is being used. This average time counter measures the time the host takes to
respond to a request sent to it. The time starts after TI sends the final data buffer and ends when the
Host resp time TCP IMS Connect or OTMA

TCP/IP IMS Explicit model is being used. This average time counter measures the time the host takes to
respond to a request sent to it. The time starts after TI sends the final data buffer and ends when the
IMS Connect or OTMA enables customers to connect to existing IMS transactions without linking
listeners to the transaction programs (TP), so you do not have to recompile your IMS TP.
Link calls / sec

Displays the number of method calls that use the CICS LINK programming model. This number
represents calls-per-second.
Non-link calls / sec

Displays the number of method calls that use the CICS Non-LINK or IMS programming model. This
number represents calls-per-second.
Page 15 of 50
TCP Concurrent Server calls / sec
Displays the number of method calls that use the TCP/IP CICS Concurrent Server programming model.
This number represents calls-per-second.
TCP MSLink calls / sec

Displays the number of method calls per second that use the TCP/IP CICS MS Link programming model.
TCP OTMA calls / sec

Displays the number of method calls that use the TCP/IP OTMA programming model. This number
represents calls-per-second.
Total calls / sec

Displays the total number of method calls per second that TI has processed. This counter is not specific
to any TI programming model.
Total errors / sec

Displays the total number of method calls per second that have returned a non-zero HRESULT to the
client application. This counter is not specific to any TI programming model.
Page 16 of 50
SNA Communications Elements
The section describes the major factors that affect Transaction Integrator (TI) throughput over the
APPC/LU 6.2 SNA transport.
LU 6.2 Contention Winner Limit

Transaction Integrator (TI) uses only LU 6.2 contention winner sessions. The number of sessions
negotiated with the host system determines the number of sessions available for concurrent TI client
requests. The parallel session limit and contention winner limit should be set to the same value within
the Host Integration Server APPC mode definition used by TI.
In addition, the Request/Response Unit (RU) size should be sufficiently large to hold the standard
message size sent between TI and the host application.
For example, if the host response is expected to exceed 2 KB, set the Max Send and Receive RU size to
4096 within the Host Integration Server APPC mode definition. The session level pacing values will not
likely affect transaction performance because a transaction may only involve a single request and single
(under 4 KB) response.
In this case, an APPC mode send and receive window of two or more should be sufficient. However, if a
large host response is expected, it is recommended to use a larger RU size to reduce SNA-level message
acknowledgements.
Pre-Activation of the LU 6.2 Sessions

Activating LU 6.2 sessions in advance will automatically prevent a short delay in establishing new LU 6.2
sessions as Transaction Integrator (TI) conversation allocation requests are made. In addition, pre-
activating sessions keeps idle sessions active during the SESTIMEOUT period (approximately 20 seconds).
Host Integration Server 2006 honors its APPC mode automatic activation limit setting for any APPC
LU/LU partnership defined within the APPC mode when the connection is initially activated. Partnerships
are defined in the APPC-mode Partners tab.
SNA Link Tuning

If you are using token-ring, Ethernet, or FDDI to communicate with your host system, investigate data
link control (DLC) tuning. The following 802.2 connection default settings should be sufficient:
Unacknowledged Send limit is 8 by default.
Receive ACK threshold is 2 by default. However, some hosts are set to a Send Window of 1, so they
require an ACK from Host Integration Server 2006 for every frame they send; whereas with the default
of 2, the host can stop sending until the ACK has been received. The DLC will then go through the time-
out and recovery, but the performance will be decreased significantly. It is important that you set each
node's send window to be larger than its partner's receive window.
Page 17 of 50
Maximum BTU length: 1929 for token-ring, 1493 for Ethernet. If a 16-Mbps token-ring is being used, and
the TI request or host response will exceed this BTU length, increase the maximum BTU length to 4105
(or 8192 for the maximum possible) within the Host Integration Server connection.
Host (VTAM, CICS or IMS) Response Time

The host response time, also called the unit of work (UOW) or host processing time, for each transaction
affects the number of transactions that can be performed given the number of LU 6.2 sessions that are
used.
If CICS is used, investigate the CICS region definitions for parallel session limit and contention winner
limit. These values are configured in the Maximum parameter in the CICS region SESSION PROPERTIES:
SESSION PROPERTIES Maximum==>100, 000
The first value is the parallel session limit and the second value is the CICS contention winner limit. For
Transaction Integrator (TI) use, Host Integration Server should be configured as the contention winner
for all sessions, so you should set the CICS contention winner limit to zero (0). Also, verify that the CICS
region maximum tasks value is sufficient to handle the concurrent client requests.
If you are using IMS, verify that IMS has sufficient message processing regions to handle the expected
load.
Page 18 of 50
Windows Server 2003 Tuning
Adjusting Application Priority
Based on scenarios representing normal loads, Microsoft Windows Server® 2003 tasking priorities do
not need to be adjusted. However, by adjusting the balance between background and foreground
applications, it is possible to squeeze more server task performance out of the system to cover peak
loads. An even balance between the two provides background applications a better response time, but
still gives more processor time to the foreground application.
To Adjust the Balance

1. On the Start menu, point to Settings, and then click Control Panel.
2. In Control Panel, double-click the System icon, and then select the Advanced tab.
3. On the Performance button, choose to optimize performance for background services and then click
OK.
Reducing Context Switching
Context switching is one of the most common explanations for degraded server performance on any
operating system. Windows Server 2003 is no exception. If a system is doing more than 50,000 context
switches per second (unlikely, but nonetheless possible), it does not have time to do actual work.
Instead, it is spending all its time switching various code and data pages in and out of its memory to the
L2 cache, RAM, or even to the disk drive—in other words, the system is thrashing.
A high total, active thread count on the system is a certain cause of context switching. In the “Long-
Running Transactions” section, this paper introduces two registry entries that can increase the thread
count for a Microsoft Transaction Server (MTS) package and TI 2PC transactions. Care must be taken
when the thread counts are adjusted to gain optimum performance.
Note: It is advisable to track context switching / second when these adjustments are made.
In addition to adjusting MTS and TI threading, it is possible to adjust the HIS Server asynchronous I/O
threading model. These threads only serve the HIS Server client traffic. They are designed to handle the
full 30,000 sessions, hitting the HIS Server with over 1,000 TPS. Performance testing in the lab
environment has shown no reason for adjusting these values.
However, since TI represents only one client to the HIS Server, adjustments can be made if you
absolutely must minimize the thread count in your system. The thread count is calculated as follows:
HIS Server I/O thread count = Base thread count + Additional threads x Number of CPUs
Base thread count is 5
Default additional threads per CPU is 4
Adjust by specifying the number of additional threads per CPU by adding a DWORD value
NumberofIOthreads to the registry location:
Page 19 of 50
HKLM\System\CurrentControlSet\Services\SNAServer\
parameters
Valid values are: Up to a total of 64 maximum I/O threads per system
Streamlining Authentication
TI users are typically authenticated on a transaction-by-transaction basis for both a Windows NT®
domain and a host domain. Host Integration Server provides the necessary security integration between
these systems. The Already verified parameter could be set to streamline the authentication on the host
side.
Both TI and the SNA Server node maintain a cache of verified domain/user names in a secured location.
To guarantee fast access to the Windows Server 2003 authentication, install in the same LAN segment
the primary or backup Windows Server 2003 domain controllers, TI, and Host Integration Server. Doing
so helps eliminate delays caused by bridging or routing.
Optimizing Network Throughput
Network priority can be adjusted to guarantee the best possible networking throughput. (Basically, you
adjust the relationship between memory allocated to network connections and memory allocated to
applications running on your computer.)
To Adjust Network Priority in Windows Server 2003

1. On the Start menu, point to Settings, and then click Control Panel.
2. In Control Panel, double-click the Network and Dial-up Connections icon.
3. Double-click the Local Area Connection that will be handling the Host Integration Server network
traffic, then click Properties.
4. In the Properties dialog box, select File and Printer Sharing for Microsoft Networks, and then click
Properties.
5. In the Properties Page for File and Printer Sharing for Microsoft Networks select Maximize Data
Throughput for Network Applications, and then click OK.
The Maximize Throughput for Network Applications option optimizes server memory for distributed
applications that do their own memory caching. Your network adapter can have a large impact on your
overall performance. Some advanced adapters provide setup options for optimizing network I/O
performance. The parameters to look for are I/O buffering on the card itself, direct memory access
(DMA), adjustable data link control (DLC) maximum frame size, and LAN speed setting.
Page 20 of 50
IIS 6.0 Server Tuning
Connections
You can set the length of time in seconds before the server disconnects an inactive user. This ensures
that all connections are closed if the HTTP protocol fails to close a connection. Most Web browsers ask
the server to keep the connection open across multiple requests. This is referred to as an HTTP Keep-
Alive, an HTTP specification that allows for greatly enhanced server performance. Without it, a browser
has to make numerous connection requests for a page containing multiple elements, such as graphics.
A separate connection may need to be made for each element. These additional requests and
connections require additional server activity and resources, decreasing server efficiency.
Additional requests also make a browser much slower and less responsive, especially across a high-
latency (slow) connection. HTTP Keep-Alives are enabled by default during the installation process.
Connection timeout
Type a number in the box to set the length of time, in seconds, before the server disconnects an inactive
user. This ensures that all connections are closed if the HTTP protocol fails to close a connection.
Recommended Server Setting: <120
HTTP Keep-Alives
Select to enable a client to maintain an open connection with your server, rather than re-opening the
client connection with each new request. Disabling Keep-Alives may degrade server performance. HTTP
Keep-Alives are enabled by default.
Recommended Server Setting: Enabled
Logging
This option enables logging features, which records details about user activity and creates logs. Logging
information in IIS goes beyond the scope of the event-logging or performance-monitoring features of
Microsoft Windows.
The logs include information, such as who has visited your site, what the visitor viewed, and when the
information was viewed last. You can use the logs to assess content popularity or identify information
bottlenecks. Scan the log for error codes such as 404 Not Found, and take action to correct links, if
necessary.
On IIS 6.0, the substatus code is included in the log and is useful for debugging. IIS uses substatus codes
to identify specific problems. For example, 404.2 indicates that the ISAPI extension handling the request
is locked down. A list of status and substatus codes can be found in the “About Custom Error Messages”
topic.
Page 21 of 50
New for IIS 6.0, malformed or bad requests and requests that fail to be served by an Application Pool are
logged to the HTTPERR log by HTTP.SYS, the kernel-mode driver for handling HTTP requests. Each entry
includes the URL and a brief description of the error.
Check the HTTPERR log for rejected requests. Requests are rejected by HTTP.SYS when the kernel
request queue is exceeded, and when the application is taken offline by the Rapid Fail Protection
feature. When the first issue occurs, the URL is logged with the message QueueFull, and when the
second occurs, the message is AppOffline.
By default, the kernel request queue is set to 1,000, and can be configured on the Application Pool
Properties page in IIS Manager. It is recommended to increase this to 5,000 for a busy site, since the
kernel request queue could easily surpass 1,000 if an Application Pool crashes while a site is under a
very high load.
Check the HTTPERR log for requests lost due to a worker process crash or hang. When this occurs the
URL will be logged with the message, Connection_Abandoned_By_AppPool, for each in-flight request.
An in-flight request is one that was sent to a worker process for processing, but did not complete before
the crash or hang.
Addition Information:
http://support.microsoft.com/default.aspx/kb/820729
Bandwidth throttling
If the network or Internet connection used by your Web server is also used by other services, such as e-
mail or news, you can limit the bandwidth used by your Web server so that the server is available for
those other services. If the web servers at your company are dedicated to web traffic, bandwidth
throttling is not required.
Recommended Server Setting: Disabled
Web Site Connections

Limiting server connections better optimizes performance by reserving bandwidth for the number of
connections within the specified connection limit. It is often used on servers that serve multiple
purposes, such as e-mail, news, and FTP. If your web servers are dedicated to web traffic, bandwidth
throttling should not be required.
ISAPI Filters
Basically, they are programs (non-cgi executables) written to interact and work with requests to a web
server. There are two forms of ISAPI programs – extensions and filters. Most companies utilize two ISAPI
Page 22 of 50
Filters: Microsoft’s URLSCAN and ASP.NET_1.1.4322.2300. Unless necessary, non-Microsoft ISAPI filters
are not recommended because if the filter crashes it brings down the whole web server.
Recommended Server Setting: Microsoft Only ISAPI Filters
Application Configuration
All web servers have Application Pools defined. Caching ISAPI extensions is enabled and recommended.
Session State
Session state plays a significant role in IIS performance and resource usage. When session state is
enabled, IIS creates a session for each user who accesses an ASP application. Session information is used
to track the user within the application and to pass user information from one page to another.
The Session object and its associated properties are stored in memory on the server. The user’s session
ID is passed to the user’s browser as a cookie. As long as the browser accepts cookies, the session ID is
passed back to the server on subsequent requests. This is true even if the user requests a page in a
different application. The same ID is used in order to reduce the number of cookies sent to the browser.
Keep in mind that if the browser doesn’t accept cookies, the session ID can’t be maintained and IIS can’t
track the user session using this technique. In this case you could track the session state on the server.
Session state is enabled by default for all IIS applications. By default, sessions time out in 20 minutes.
This means that if a user doesn’t request or refresh a page within 20 minutes, the session ends and IIS
removes the related session object from memory. You can change the default time-out value using the
Session Timeout property on the Options tab of the Application Configuration property sheet.
Worker process recycling can affect session management. If a worker process is recycled or otherwise
cleared out of memory, the session state could be lost. If this happens, you won’t be able to recover the
session data.
Tracking sessions can use valuable system resources. The best practice recommendation is to either
reduce resource usage by reducing the time-out interval or disabling session tracking altogether.
Reducing the time-out interval allows sessions to expire more quickly than usual. Disabling session
tracking tells IIS that sessions shouldn’t be automatically created.
Buffering
Buffering is another option that affects server performance and resource usage. When buffering is
enabled, IIS completely processes pages before sending content to the client browser. When buffering is
disabled, IIS returns output to the client browser as the page is processed. The advantage to buffering is
that it allows you to respond dynamically to events that occur while processing the page.
A disadvantage of buffering is that users have to wait for the entire script to be processed before
Page 23 of 50
content is delivered to their browser. If a script is long or complex, the user might have to wait for a long
time before seeing the page.
Parent Path, Default ASP Language, and ASP Script Time-Out
Enable Parent Paths allows ASP pages to use relative paths to access the current directory’s parent
directory. For example, a script could reference ../Build.htm, where “..” is a reference to the current
directory’s parent directory. Parent paths are enabled by default. As a best practice, it is recommended
that parent paths are disabled, because a script could execute an unauthorized program in a parent
directory.
Default ASP Language sets the default scripting language for ASP pages. Two scripting engines are
installed with a standard IIS installation. These scripting engines are for VBScript and JScript®. You can
reference these scripting engines using the values VBScript and JScript, respectively. VBScript is the
preferred and recommended best practice.
Recommended Server Setting: VBScript
ASP Script Timeout sets the length of time that IIS allows a script to run. If a script doesn’t complete
within the time-out interval, IIS stops the script and writes an error to the application event log. The
default time-out value is 90 seconds, but you can set a new default value at any time. The longer the
interval is set, the longer resources are held and server performance is degraded. Therefore, the
recommended setting is to reduce this if you currently have scripts below this threshold.
Recommended Server Setting: NON DEFAULT
ASP server-side script and client-side script debugging

This should only be enabled when troubleshooting issues in production. However, these should be set in
the QA environment allowing the ability to troubleshoot issues.
Cached limited ASP Files in memory

ASP processes the files that contain ASP scripts, stores these processed files in a cache, and then serves
the cached files to clients. Caching ASP script files enhances performance because cached ASP scripts are
not compiled each time they are called. For optimal performance, the cache should be twice the number
of files for growth.
Recommended Server Setting: TWICE THE NUMBER OF FILES
Page 24 of 50
Cached limited ASP Files on disk
The ASP disk cache begins caching files into a directory when the ASP memory cache is full.
Furthermore, a file has to be requested at least twice before it becomes a candidate for the ASP disk
cache.
Recommended Server Setting: FOUR TIMES THE FILES IN MEMORY
IIS 5 Isolation Mode

IIS 5.0 isolation mode provides as much compatibility as possible for applications that were developed
for IIS 5.0. For example, the request processing of IIS 6.0 when it is running in IIS 5.0 isolation mode is
nearly identical to the request processing of IIS 5.0. Hence, in IIS 5.0 isolation mode, you can run read
raw data filters and can run applications in Inetinfo.exe or in DLLHost.exe — all of which is not
accommodated in worker process isolation mode. If the web site runs only IIS 6, this setting is not
needed.
HTTP compression
HTTP compression provides faster transmission time between compression-enabled browsers and IIS.
When IIS receives a request, it checks to see if the browser is compression-enabled. IIS then checks the
file name extension to determine whether the requested file contains either static or dynamic content.
If the file contains static content, IIS checks to see if the file is already stored in a compressed format in
the cache. If it is, IIS sends the compressed file to the browser.
If the file is not stored in a compressed format, IIS sends the uncompressed file to the browser and adds
a compressed copy of the file to the cache. If the file contains dynamic content, IIS compresses the file
as it is generated and sends the compressed file to the browser.
The performance cost of compressing a static file is modest and is typically incurred only once because
the file is then stored in the temporary compression directory. The cost of compressing dynamically
generated files is somewhat higher, because they are not stored and must be regenerated with each
request. The cost of expanding the file at the browser is minimal. Compressed files download faster,
which makes them particularly beneficial to the performance of any browser that uses a network
connection with restricted bandwidth (a modem connection, for example).
While this does add minimal processing overhead, the general best practice is to enable HTTP
compression for faster processing of pages and for a better browsing experience for users conning via
slower connections. However, if your company utilizes extensive proxy and caching servers, this setting
is not recommended.
Recommended Server Setting: Compress application files: Disabled; Compress static files: Disabled
Page 25 of 50
Application Pool Recommendations
ASP.NET should be running under IIS 6 in native mode for all servers. These settings are configured
within IIS6 UI.
Below are the recommended application pool settings for most IIS servers:
Recycle worker process processes (in minutes):

Recycle worker process (number of requests):

Recycle worker process at the following times:

Recommended Server Setting: Enabled, 3:00 AM
Memory Recycling
It is recommended that companies restrict resource usage by implementing memory-based recycling.

This setting will recycle the worker process after a certain amount of memory is used, so that other sites
on the system will not deteriorate for one site over-using memory.
Maximum virtual memory (in megabytes):

As applications reserve memory multiple times, the memory heap becomes highly fragmented which
then creates a steady increase in virtual memory. This will periodically increase virtual memory without
subsequently releasing it. In this way, virtual memory can increase indefinitely. To limit the impact of
increased virtual memory, you should set an application pool to recycle the worker processes that are
assigned to it whenever virtual memory reaches a specified threshold. The best practice is to enable this
setting and to specify the value at 60 percent of available virtual memory.
Recommended Server Setting: 70% of available Virtual Memory
Maximum used memory (in megabytes):

This setting recycles the worker process when the memory that is used by the W3wp.exe process
reaches a threshold. This is a vital setting that many companies use to control memory leaks which
indefinitely increases the amount of memory used without releasing the memory.
Recommended Server Setting: 60% of system memory (Max 800 MB)
Idle timeout
It is recommended to enable Idle Timeout, which is a feature that allows timeout and shutdown for an
idle worker processes. This ensure that unused/infrequent use of application pools do not consume CPU
or memory resources. However, starting up a worker process also takes resources. Therefore, it is
recommended that the time be extended to 120 minutes (or more) to only shut down the worker
Page 26 of 50
processes that are truly unused as opposed to rarely used.
Recommended Server Setting: Enabled, 120
Request Queue Limit

After HTTP.sys detects the TCP/IP thread, it either begins serving the request with content stored in the
HTTP.sys cache, if available (this is called a cache hit), or puts the request in a kernel request queue for
the designated application pool. Because the request is still in the kernel, but is waiting in a queue for a
specific application pool, this queue is called the application pool queue. In IIS Manager, this queue is
called the kernel request queue.
When IIS 6.0 runs in worker process isolation mode or native mode, by default HTTP.sys checks the
number of requests for a designated application pool queue before it adds a new request to the queue.
If adding the new request to the queue exceeds the queue limit, the server rejects the request, logs a
QueueFull error in the HTTP error log, and sends a 503 error (Service Unavailable) to the client. This 503
error response cannot be customized.
Without a kernel request limit, IIS could queue an unlimited number of requests and your server could
potentially run out of memory. For this reason, you should set kernel request-queue limits on all
production servers.
Recommended Server Setting: Enabled, >1000 (TEST 5000)
CPU Monitoring
IIS can be configured to use CPU monitoring to track and terminate worker processes that consume
large amounts of CPU time that exceed specified limits. This built-in CPU monitoring does little more
than turn the application on and off and is not recommended for most companies.
Web Garden
Web gardens are a tool for maintaining application performance as opposed to isolation which would be
an application pool and/or domain. Just to clarify, application pools are isolation boundaries.
We see and recommend web gardens in environments where we have contention in applications. What
we have seen at most companies is contention where they have multiple requests coming into a
process, and within that process locking is taking place. Therefore, it is recommended to increase the
Web Garden from 1 to 2 to balance out requests to other non-blocked processes. This way, if locking
does occur within one process, it may not be a problem in another and the site can continue with less
impact to users. However, before increasing this number, a code review should be performed to the
application can properly function in multi-instances.
Recommended Server Setting: NON DEFAULT (TEST 2)
Page 27 of 50
Pinging
The World Wide Web Publishing Service (WWW service) monitors the health of worker processes by
periodically pinging them to determine their responsiveness. If a worker process fails to respond to a
ping, the WWW service terminates the worker process and creates another worker process as a
replacement. Additionally, the WWW service maintains a communication channel to each worker
process, and it can detect a drop in the communication channel, which indicates a worker process
failure. When a worker process fails on its own accord, the WWW service starts another worker process
in its place.
The beauty of this is the end users don’t see any downtime, because the Http.sys will get the request,
will queue it, and then the WAS will start up a new worker process, and a new worker process will
service it.
Recommended Server Setting: 10
Rapid fail protection

If a particular application pool experiences consecutive multiple failures, the application pool can be
automatically disabled, allowing for rapid-fail protection to start. The application pool is taken out of
service and placed in a state such that the kernel-mode driver immediately returns an out-of-service
message (503: Service Unavailable) to any requests to that application pool. When such a condition
occurs, the Web administration service disables the application pool, preventing future failures and
making the application unavailable until the administrator intervenes. If you have a 24x7 site, it is
recommended that the feature be disabled so that requests can always be processed.
Startup time limit

It is important to tune the startup time period to fit the load characteristics of the applications that are
being processed. By default, the worker process startup time limit is enabled in IIS 6.0 with a default
setting of 90 seconds.
Shutdown time limit

When IIS 6.0 detects that a worker process is unhealthy, IIS 6.0 marks the worker process for
termination. The shutdown time limit specifies how long IIS waits until forcibly terminating the worker
process when the worker process does not shut down automatically.
By default, worker process shutdown time limit is enabled in IIS 6.0 with a default of 90 seconds. It is
important to tune the shutdown time period to fit the load characteristics of the applications that are
being processed.
Page 28 of 50
Additional Technical Resources
Microsoft provides the following resources to gather more information on Host Integration Server 2006
(HIS 2006):
Web Sites
Host Integration Server on TechNet

Microsoft's destination for IT professionals, Microsoft TechNet, provides the tools, software
and resources to help you plan, build, deploy, and support Host Integration Server.
Host Integration Server Developer Center

Microsoft's destination for developers, MSDN®, provides technical reference and how-to
resources to help you develop for Host Integration Server.
Web Casts (Applicable to HIS 2006)
MSDN Webcast: Host Integration Server 2004 Transaction Integrator - Level 200
MSDN Webcast: Host Integration Server 2004 Host-Initiated Processing - Level 200
MSDN Webcast: Host Integration Server 2004 Data Providers for Host Files - Level 200
MSDN Webcast: Host Integration Server 2004 Data Providers for DB2 - Level 200
MSDN Webcast: Host Integration Server 2004 Extends BizTalk Solutions - Level 200
MSDN Webcast: BizTalk Adapter for Host Applications – Level 200
Microsoft Executive Circle Webcast: Services-Oriented Architectures Based on Host Integration Server
2004
TechNet Webcast: Host Integration Server 2004 Network Integration - Level 200
TechNet Webcast: Host Integration Server 2004 Secure Deployment - Level 200
Page 29 of 50
Appendix I: Test Parameters
ELM Link Direct Call heavy conversion
TIPerformance Host
UOW (ms) 0
2PC Prepare (ms) 0
TIPerformance Client
Menu Settings
Mode Manual
Options Non-Transactional, In/Out
Hosting Mode Self-hosting/Direct call

Comm Model TCP CICS ELM Link
Test Characteristics
Test iterations 10000
Number of Clients 33
Number of Hosts 4
Client start delay (ms) 0
Client rate (Trans.) 0
Client rate (Seconds) 0
Machine Localhost
Virtual Directory TIPerformance
Path c:\TI Performance
Tools\TIPerformanceClient
Call Characteristics
Return Value Only FALSE
CHAR Data Only FALSE
All Data Types TRUE
All Types no Data Table FALSE
CHAR Data with Data Table FALSE
Mixed Data Char, Float, Pack FALSE
Mixed Real World FALSE
CHAR Data Structure FALSE
All Types Structure FALSE
Mixed Data CFP Structure FALSE
Emul 3270 CFP (201,1961) FALSE
All Types no Data Table Big FALSE
Page 30 of 50

ELM Link Direct Call medium conversion

TIPerformance Host
UOW (ms) 0
2PC Prepare (ms) 0
Menu Settings
Mode Manual

Number of Hosts 4
Machine localhost
All Data Types FALSE
Mixed Data Char, Float, Pack TRUE

Page 31 of 50
Byte Count 509
Page 32 of 50
ELM Link Direct Call medium conversion with 500ms of host UOW time
TIPerformance Host
UOW (ms) 500
2PC Prepare (ms) 0
Menu Settings
Mode Manual

Test iterations 100
Number of Hosts 4
Machine localhost

Byte Count 509
Page 33 of 50
ELM Link Direct Call medium conversion with RE Override
TIPerformance Host
UOW (ms) 0
2PC Prepare (ms) 0
Menu Settings
Mode Manual
Options Non-Transactional,
In/Out,RE Override

Number of Hosts 4
Machine localhost

Byte Count 509

Page 34 of 50
ELM Link Direct Call medium conversion 2PC
TIPerformance Host
UOW (ms) 0
2PC Prepare (ms) 500
Menu Settings
Mode Manual

Test iterations 100
Number of Hosts 4
Machine localhost

Byte Count 509
Page 35 of 50
IMS Connect medium conversion

TIPerformance Host
UOW (ms) 0
2PC Prepare (ms) 0
Menu Settings
Mode Manual
Comm Model TCP IMS Connect
Number of Hosts 4
Machine localhost

Byte Count 509
Page 36 of 50
IMS Connect medium conversion 2PC
TIPerformance Host
UOW (ms) 0
Menu Settings
Mode Manual
Comm Model TCP IMS Connect
Number of Hosts 4
Machine localhost

Byte Count 509
Page 37 of 50
ELM Link Direct Call light conversion
TIPerformance Host
UOW (ms) 0
2PC Prepare (ms) 0
Menu Settings
Mode Manual

Number of Hosts 4
Machine localhost
CHAR Data Only TRUE

Byte Count 485
Page 38 of 50
ELM Link Direct Call Light + UDTs
TIPerformance Host
UOW (ms) 0
2PC Prepare (ms) 0
Menu Settings
Mode Manual

Number of Hosts 4
Machine localhost
CHAR Data Structure TRUE

Byte Count 485
Page 39 of 50
ELM link Direct Call Light + Data Set

TIPerformance Host
UOW (ms) 0
2PC Prepare (ms) 0
Menu Settings
Mode Manual

Number of Hosts 4
Machine localhost
CHAR Data with Data Table TRUE

Byte Count 485
Page 40 of 50
IIS + ELM Link TI Web Services (Data Sets)

TIPerformance Host
UOW (ms) 0
2PC Prepare (ms) 0
Menu Settings
Mode Manual
Hosting Mode Web Services
Number of Hosts 4
Machine Ditto
Virtual Directory Ditto
Path Ditto
Mixed Data CFP Structure TRUE

Byte Count 485
Page 41 of 50
IIS + ELM Link .NET Remoting (Data Tables)

TIPerformance Host
UOW (ms) 0
2PC Prepare (ms) 0
Menu Settings
Mode Manual
Number of Hosts 4
Machine Ditto
Virtual Directory Ditto
Path Ditto
Mixed Data CFP Structure TRUE

Byte Count 485
Page 42 of 50
ELM Link with Persistent Connection medium conversation

TIPerformance Host
UOW (ms) 0
2PC Prepare (ms) 0
Menu Settings
Mode Manual
Options Non-Transactional, In/Out,Use
Persistent Connection

Test iterations 2 (Client will only allow 2)
Number of Hosts 4
Machine localhost

Byte Count 509
Page 43 of 50
ELM Link with Persistent Connection medium conversation 2PC

TIPerformance Host
UOW (ms) 0
Menu Settings
Mode Manual
Options Non-Transactional, In/Out,
Use Persistent Connection

Test iterations 2
Number of Hosts 4
Machine localhost

Byte Count 509
Page 44 of 50
TRM Link Direct Call medium conversation
TIPerformance Host
UOW (ms) 0
2PC Prepare (ms) 0
Menu Settings
Mode Manual
Comm Model TCP CICS TRM Link
Number of Hosts 4
Machine localhost

Byte Count 509
Page 45 of 50
IIS + ELM Link TI Web Services medium conversion
TIPerformance Host
UOW (ms) 0
2PC Prepare (ms) 0
Menu Settings
Mode Manual
Number of Hosts 4
Machine localhost

Byte Count 509
Page 46 of 50
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication.
Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft
cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE
INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may
be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying,
recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document.
Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
 2008 Microsoft Corporation. All rights reserved.
Microsoft, BizTalk, Expression, JScript, MSDN, Silverlight, Visual Studio, Windows, Windows NT, and Windows Server are trademarks of the Microsoft
group of companies.
All other trademarks are property of their respective owners.
Page 47 of 50
Page 48 of 50

Host Integration Server 2006 TI Performance

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Host Integration Server 2006 TI Performance

Uploaded by

Copyright:

Available Formats

MicrosoftHost Integration Server 2006

Transaction Integrator Performance White Paper

Published: February 2008

EXECUTIVE SUMMARY AND RESULTS...................................................................................................6

TI PERFORMANCE LAB OVERVIEW.......................................................................................................7

HOST EMULATOR SERVER...................................................................................................................7

© Microsoft Corp. 2008

APPENDIX I: TEST PARAMETERS........................................................................................................29

ELM LINK DIRECT CALL HEAVY CONVERSION..................................................................................................29

© Microsoft Corp. 2008

 BizTalk Adapter for Host Systems

If further clarification is required, please contact THG at [email protected] or contact your

Host Integration Server Transaction Integrator 2006

TI Performance Lab Overview

HOST EMULATOR SERVER

TI / HIS / BizTalk 2006 SERVER

TI Performance Lab Test Cases

A typical scenario involves the following steps:

 The IT professional installs the adapter.

o Defining the Remote Environment

 BizTalk Adapter for Host Applications No Conversion – Non-Persistent Connection

 ELM Link Direct Call Heavy Conversion

 TRM Link Direct Call medium conversation

 IMS Connect medium conversion

 IIS + ELM Link TI Web Service medium conversation

Windows Server 2003 Central Location – Data Center

Smart Client z/OS

RACF Security Authentication

Internet Host Integration

Host Internal Response Time

External Computer Response Time

True User Response Time

Average method call time

Bytes recv'd from a TCP host / sec

Bytes recv'd from an SNA host / sec

Bytes sent to a TCP host / sec

Bytes sent to an SNA host / sec

Calls currently executing

Host resp time CICS Link

Host resp time CICS Non-link or IMS

Host resp time TCP Concurrent Server

Host resp time TCP MS Link

Host resp time TCP IMS Connect or OTMA

Link calls / sec

Non-link calls / sec

TCP MSLink calls / sec

TCP OTMA calls / sec

Total calls / sec

Total errors / sec

LU 6.2 Contention Winner Limit

Pre-Activation of the LU 6.2 Sessions

SNA Link Tuning

Unacknowledged Send limit is 8 by default.

Host (VTAM, CICS or IMS) Response Time

SESSION PROPERTIES Maximum==>100, 000

To Adjust the Balance

Reducing Context Switching

Optimizing Network Throughput

To Adjust Network Priority in Windows Server 2003

Recommended Server Setting: <120

Recommended Server Setting: Enabled

Recommended Server Setting: Enabled

Recommended Server Setting: Disabled

Web Site Connections