host integration server 2006 ti performance

Microsoft Host 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............................................................................................................7TI / HIS / BIZTALK 2006 SERVER.......................................................................................................7

TI PERFORMANCE LAB TEST CASES...................................................................................8

BIZTALK TESTS.............................................................................................................................8ELM TESTS................................................................................................................................9TRM TESTS..............................................................................................................................10IMS TESTS...............................................................................................................................10IIS TESTS.................................................................................................................................10

GENERAL TI SERVER PERFORMANCE TUNING......................................................................11

TI PERFORMANCE ELEMENTS............................................................................................................11Host Internal Response Time...................................................................................................11External Computer Response Time............................................................................................12Network Delay.....................................................................................................................12True User Response Time........................................................................................................12SNA Communications Elements......................................................................................16

WINDOWS SERVER 2003 TUNING......................................................................................................18Adjusting Application Priority..................................................................................................18Reducing Context Switching....................................................................................................18Streamlining Authentication....................................................................................................19Optimizing Network Throughput..............................................................................................19

IIS 6.0 SERVER TUNING.................................................................................................................20Connections........................................................................................................................20Connection timeout...............................................................................................................20HTTP Keep-Alives..................................................................................................................20Logging.............................................................................................................................20Bandwidth throttling.............................................................................................................21Web Site Connections............................................................................................................21ISAPI Filters.........................................................................................................................21Application Configuration.......................................................................................................22Session State.......................................................................................................................22Buffering............................................................................................................................22Parent Path, Default ASP Language, and ASP Script Time-Out...........................................................23ASP server-side script and client-side script debugging....................................................................23

© Microsoft Corp. 2008

Cached limited ASP Files in memory...........................................................................................23Cached limited ASP Files on disk...............................................................................................24IIS 5 Isolation Mode..............................................................................................................24HTTP compression................................................................................................................24Application Pool Recommendations...........................................................................................25Memory Recycling................................................................................................................25Maximum virtual memory (in megabytes):..................................................................................25Maximum used memory (in megabytes):....................................................................................25Idle timeout........................................................................................................................25Request Queue Limit.............................................................................................................26CPU Monitoring...................................................................................................................26Web Garden.......................................................................................................................26Pinging..............................................................................................................................27Rapid fail protection..............................................................................................................27Startup time limit.................................................................................................................27Shutdown time limit..............................................................................................................27

ADDITIONAL TECHNICAL RESOURCES...............................................................................28

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

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


Microsoft Host Integration Server 2006 Transaction Integrator Performance White PaperPublished: February 2008

IntroductionThis 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).

of 49http://www.microsoft.com/hiserver


http://www.amd.com/

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.



http://www.microsoft.com/hiserver

mailto:[email protected]

http://www.HensonGroup.com/

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 2006on a Dual-Core AMD Opteron Processor 2220 SE 2.81 GHz

Transaction Size(485-509 bytes in/out)

Throughput(TPS)

Response Time(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

IIS + ELM Link .NET Remoting (Data Tables) 442 69

TI Performance Lab OverviewMicrosoft and The Henson Group built a lab comprising of two Dual-Core AMD Opteron 2220 SE servers.

HOST EMULATOR SERVERCPU 1: Dual-Core AMD Opteron Processor 2220 SE 2.81 GHzCPU 2: Dual-Core AMD Opteron Processor 2220 SE 2.81 GHzRAM: 7.87 GBHard Drives:

Disk 0, 7,200 rpm, 300 GB, SATA raidVolume C: 152,664 MBVolume D: 152,578 MB

OS: Windows Server® 2003 Enterprise x64 Edition with Service Pack 2

TI / HIS / BizTalk 2006 SERVERCPU 1: Dual-Core AMD Opteron Processor 2220 SE 2.81 GHzCPU 2: Dual-Core AMD Opteron Processor 2220 SE 2.81 GHzRAM: 7.87 GBHard Drives:

Disk 0, 7,200 rpm, 300 GB, SATA raidVolume C: 152,664 MBVolume D: 152,578 MB

OS: Windows Server 2003 Enterprise x64 Edition with Service Pack 2



TI Performance Lab Test Cases

BizTalk TestsThe 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 Environmento Building the TI Assembly and Schemao Deploying, Testing, and Debugging the Applicationo 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



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 TestsThe 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



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 TestsThe 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 TestsThe 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 TestsA 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)



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.

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



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



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



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:

Two-phase commit (2PC) response time is not considered and is omitted from the calculation. 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:

Two-phase commit (2PC) response time is not considered and is omitted from the calculation. 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 Measures the average time the host spends processing the transaction programs unit of work when the 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 first response buffer is received by TI. This counter is represented in terms of seconds of elapsed time.

Host resp time TCP IMS Connect or OTMA Measures the average time the host spends processing the transaction programs unit of work when the 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 first response buffer is received by TI. This counter is represented in terms of seconds of elapsed time. 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.



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.



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.



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.



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 CPUsBase thread count is 5Default additional threads per CPU is 4Adjust by specifying the number of additional threads per CPU by adding a DWORD value

NumberofIOthreads to the registry location:



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.



IIS 6.0 Server Tuning

ConnectionsYou 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 timeoutType 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-AlivesSelect 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

LoggingThis 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.



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 throttlingIf 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 ConnectionsLimiting 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 FiltersBasically, 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



http://support.microsoft.com/default.aspx/kb/820729

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 ConfigurationAll web servers have Application Pools defined. Caching ISAPI extensions is enabled and recommended.

Session StateSession 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.


BufferingBuffering 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



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 debuggingThis 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 memoryASP 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



Cached limited ASP Files on diskThe 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 ModeIIS 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 compressionHTTP 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



Application Pool RecommendationsASP.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): Recommended Server Setting: Disabled

Recycle worker process (number of requests): Recommended Server Setting: Disabled

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 timeoutIt 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



processes that are truly unused as opposed to rarely used.

Recommended Server Setting: Enabled, 120

Request Queue LimitAfter 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 MonitoringIIS 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 GardenWeb 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)



PingingThe 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 protectionIf 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 limitIt 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 limitWhen 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.




Additional Technical ResourcesMicrosoft provides the following resources to gather more information on Host Integration Server 2006 (HIS 2006):

Web Sites

Host Integration Server on TechNetMicrosoft'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 CenterMicrosoft'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



http://go.microsoft.com/fwlink/?LinkId=30953




http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032330320&CountryCode=US






http://msdn.microsoft.com/hiserver/

http://www.microsoft.com/technet/prodtechnol/host/default.mspx

Appendix I: Test Parameters

ELM Link Direct Call heavy conversion

TIPerformance Host UOW (ms) 0 2PC Prepare (ms) 0TIPerformance 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



ELM Link Direct Call medium conversion


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 FALSE All Types no Data Table FALSE CHAR Data with Data Table FALSE Mixed Data Char, Float, Pack TRUE 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



Byte Count 509



ELM Link Direct Call medium conversion with 500ms of host UOW timeTIPerformance Host UOW (ms) 500 2PC Prepare (ms) 0TIPerformance Client Menu Settings Mode Manual Options Non-Transactional, In/Out


TIPerformanceClient

Call Characteristics Return Value Only FALSE CHAR Data Only FALSE All Data Types FALSE All Types no Data Table FALSE CHAR Data with Data Table FALSE Mixed Data Char, Float, Pack TRUE 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 Byte Count 509



ELM Link Direct Call medium conversion with RE OverrideTIPerformance Host UOW (ms) 0 2PC Prepare (ms) 0TIPerformance Client Menu Settings Mode Manual Options Non-Transactional,

In/Out,RE Override


TIPerformanceClient




ELM Link Direct Call medium conversion 2PC



TIPerformanceClient




IMS Connect medium conversion

TIPerformance Host UOW (ms) 0 2PC Prepare (ms) 0TIPerformance Client Menu Settings Mode Manual Options Non-Transactional, In/Out Hosting Mode Self-hosting/Direct call Comm Model TCP IMS Connect Test Characteristics Test iterations 1000 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




IMS Connect medium conversion 2PC

TIPerformance Host UOW (ms) 0 2PC Prepare (ms) 500TIPerformance Client Menu Settings Mode Manual Options Non-Transactional, In/Out Hosting Mode Self-hosting/Direct call Comm Model TCP IMS Connect Test Characteristics Test iterations 1000 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




ELM Link Direct Call light conversion



TIPerformanceClient

Call Characteristics Return Value Only FALSE CHAR Data Only TRUE All Data Types FALSE 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 Byte Count 485



ELM Link Direct Call Light + UDTs



TIPerformanceClient

Call Characteristics Return Value Only FALSE CHAR Data Only FALSE All Data Types FALSE 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 TRUE All Types Structure FALSE Mixed Data CFP Structure FALSE Emul 3270 CFP (201,1961) FALSE All Types no Data Table Big FALSE Byte Count 485



ELM link Direct Call Light + Data Set



TIPerformanceClient

Call Characteristics Return Value Only FALSE CHAR Data Only FALSE All Data Types FALSE All Types no Data Table FALSE CHAR Data with Data Table TRUE 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 Byte Count 485



IIS + ELM Link TI Web Services (Data Sets)

TIPerformance Host UOW (ms) 0 2PC Prepare (ms) 0TIPerformance Client Menu Settings Mode Manual Options Non-Transactional, In/Out Hosting Mode Web Services 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 Ditto Virtual Directory Ditto Path Ditto Call Characteristics Return Value Only FALSE CHAR Data Only FALSE All Data Types FALSE 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 TRUE Emul 3270 CFP (201,1961) FALSE All Types no Data Table Big FALSE Byte Count 485



IIS + ELM Link .NET Remoting (Data Tables)

TIPerformance Host UOW (ms) 0 2PC Prepare (ms) 0TIPerformance Client Menu Settings Mode Manual Options Non-Transactional, In/Out Hosting Mode Web Services 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 Ditto Virtual Directory Ditto Path Ditto Call Characteristics Return Value Only FALSE CHAR Data Only FALSE All Data Types FALSE 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 TRUE Emul 3270 CFP (201,1961) FALSE All Types no Data Table Big FALSE Byte Count 485



ELM Link with Persistent Connection medium conversation

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

Persistent Connection

Hosting Mode Self-hosting/Direct call Comm Model TCP CICS ELM Link Test Characteristics Test iterations 2 (Client will only allow 2) 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




ELM Link with Persistent Connection medium conversation 2PC

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

Use Persistent Connection


TIPerformanceClient




TRM Link Direct Call medium conversation

TIPerformance Host UOW (ms) 0 2PC Prepare (ms) 0TIPerformance Client Menu Settings Mode Manual Options Non-Transactional, In/Out Hosting Mode Self-hosting/Direct call Comm Model TCP CICS TRM Link Test Characteristics Test iterations 1000 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




IIS + ELM Link TI Web Services medium conversionTIPerformance Host UOW (ms) 0 2PC Prepare (ms) 0TIPerformance Client Menu Settings Mode Manual Options Non-Transactional, In/Out Hosting Mode Web Services 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




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.



host integration server 2006 ti performance

Documents