BizTalk Performance Explorer

A Script to Paste Performance Counters into PerfMon

robsteel — Wed, 27 Jun 2007 19:38:00 GMT

A Script to Paste Performance Counters into PerfMon

Overview

Click Here to download the Script and supporting files as a .zip file

If you have or know of other cool PerfMon tricks, I would very much appreciate it if you would send me a pointer.

If you've spent much time using PerfMon you may have experienced frustration with using the UI to add counters to monitor real-time. I know that I did. What I wanted was script that would take two parameters, a filename of a text file containing a list of computers and a filename of a text file containing a list of counters.

The list of computers would simply look something like the following:

Computer1

Computer2

The list of counters would simply look something list the following:

Processor(_Total)\% Processor Time

LogicalDisk(_Total)\% Disk Time

The Usage of the Script would be as follows:

PastePerfCounters.ps1 Filename_Computers.txt Filename_Counters.txt

Items to Understand First

Perfmon has a "Paste Counters" button

In the image below, please notice the button bar portion of the System Monitor Snap-In. Specifically, notice 5^th and 6^th buttons from the right. These are the "copy" and "paste counters" buttons. Many people that I talk to were not familiar with this capability of PerfMon so I'm pointing it out here. After you run the script described in this post, the clipboard will contain properly formatted text that can be pasted into PerfMon using the "paste counters" button. I'm looking for a way to automate this part too and have the counters just land in PerfMon but I haven't found a satisfying solution yet. If you have ideas, please email

Details

Perfmon Goo

In the script below, you will notice two template files are used. These two files, called BaseTemplate.txt and CounterTemplate.txt, must be located in the same directory as this script in order for everything to run as designed. These two files contain a lot of PerfMon Goo that I didn't want to put in the script. If you look at the contents of these two files, you will quickly realize that this is just a bunch of PerfMon settings. Yes, please feel free to change the template to suit your needs by modifying default values. However, if you break this file you will still copy information to the clipboard but it might not paste successfully into Perfmon or have the desired effects. To avoid problems, a good idea might be to make a backup copy of the original template files before you modify.

Non-Existent machines or counters

If you have bogus information in your lists or if the counters pasted are not functional on a machine in the computer list, then you will encounter errors. When you do, Perfmon will likely give you a dialog telling you what counters were bogus and then Perfmon will happily work with the rest.

The Script, in Powershell of course!

# Get the path to where the script lives

$ScriptBase = split-path -parent $myinvocation.mycommand.path

# In the same folder as this .ps1 file should exist the BaseTemplate.txt file

# This file contains much goo required by PerfMon to control various setttings

# You can modify this Template, but save the origional in case you make an invalid change

# Note if the BaseTemplate.txt file is not located, the script will exit with an error

$BaseTemplatePath = Join-Path $ScriptBase "\BaseTemplate.txt"

$BaseTemplateContent = Get-Content $BaseTemplatePath

Write-Output "Base path : $BaseTemplatePath"

# In the same folder as this .ps1 file should also exist the CounterTemplate.txt file

# This file contains much goo required by PerfMon to control various setttings

# You can modify this Template, but save the origional in case you make an invalid change

# Note if the CounterTemplate.txt file is not located, the script will exit with an error

$CounterTemplatePath = Join-Path $ScriptBase "\CounterTemplate.txt"

$CounterTemplateContent = Get-Content $CounterTemplatePath

Write-Output "Counter path : $CounterTemplatePath"

# Validate the the user passed in the correct number of args and

# call Write-Error to print a noticable usage statement if they did not

if ( $Args.Length -ne 2 ) {

Write-Error "usage: Add-Counters "

return

}

# If we get this far, we believe that we have two parameters which shoudl represent filenames

# for the ComputerList and the CountersList files

$ListOfComputersFile = $Args[0]

$ListOfCountersFile = $Args[1]

# Get the content from the computer and coutners files

$ComputerList = Get-Content $ListOfComputersFile

$CounterList = Get-Content $ListOfCountersFile

# Instantiate an ArrayList for us to work with

$CounterCollection = New-Object System.Collections.ArrayList

foreach ( $Computer in $ComputerList ) {

foreach ( $Counter in $CounterList ) {

if ( $Counter.IndexOf("\") -ne 0 ) {

$data = "\\$Computer\$Counter"

}else{

$data = "\\$Computer$Counter"

}

Write-Output "Adding counter : $data"

$CounterCollection.Add($data)

}

$NumberOfCounters = $CounterCollection.Count

Write-Output "Number of counters : $NumberOfCounters"

$OutputBuffer = ""

$index = 1

$color = 0

foreach ( $item in $CounterCollection) {

$indexString = "0000" + $index

if ($indexString.Length -gt 5 ) { $indexString = "000" + $index }

$OutputBuffer += [System.String]::Format($CounterTemplateContent, $item, $indexString, $color)

$index += 1

$color += 10 }

#format the output

$BaseOutputBuffer = [System.String]::Format($BaseTemplateContent, $NumberOfCounters, $OutputBuffer)

$OutputFile = "temp_" + (Get-Date).ToString("ddMMyyyyhhmmss") + ".xml"

Add-Content $OutputFile $BaseOutputBuffer

#Copy to clip board

$BaseOutputBuffer | clip

Write-Output "Successfully added $NumberOfCounters counters to the clipboard"

Asks

If you find make any improvements to this script, please blog about them and post a comment on this posting pointing to your improvements.

BizTalk Performance Lab Delivery Guide – TOC v 0.02 – Please Comment

robsteel — Wed, 27 Jun 2007 13:50:21 GMT

As promised, here is the deeper look at the Table of Contents for the BizTalk Performance Lab Delivery Guide.

As Pages are added to this site, I will update the links in this post.

Since the whole purpose of this site is to give the community a dirty read during the evolution process of the guide, please remember that everything is subject to change based upon community feedback.

Chapter 1, Introduction,

Chapter 2, A Lab Process, outlines a process and walks you through the process we use to conduct BizTalk Performance Labs on the BizTalk Ranger Team.

Chapter 3, Performance Factors, enumerates the Factors affect performance because if you don't know what to look out for it's hard to know where to start. This chapter starts by reiterating that the factors in Wayne Clark's 2004 paper are all still valid. Factors for 2006 are then discussed.

Chapter 4, Performance Metrics, is short but important as it provides reference material for learning about Performance Metrics used during a BizTalk Server Performance Lab. It's important to note that Performance Metrics involves many other technologies than BizTalk, like SQL Server, IIS, COM+, ASP.NET, etc.

Chapter 5, Performance Bottlenecks, enumerates the types of performance bottlenecks that can be encountered and offers guidance for identifying, isolating, measuring and tuning in each specific situation.

Chapter 6, Useful Tools, will probably be the most entertaining chapter since it will give how-to information on usage of various powerful tools and techniques.

Chapter 7, Engagement Documents, will provide those following the guide with a starting point from which to document the activity and planning for a performance lab engagement.

Introduction 6

What Is a BizTalk Performance Lab? 6

Who is the Audience? 6

Why was this Written? 6

A Process for Conducting Performance Labs 7

Before the Process Begins 9

The Scope Phase 9

Why Consider Scope? 10

A Document Engagement Summary 10

Hardware Diagram 14

High Level Architecture Diagram 16

The Plan Phase 16

Why Plan 17

Third-Party Software and Technology 17

Detailed Lab Hardware Stack 17

Detailed Lab Software Stack 18

Physical Space and other Logistics 18

The Prepare Phase 18

A Detailed Solution Design 19

The Application to be Tested 20

The Build Lab Phase 21

Build Lab Infrastructure 21

Configuring Third-Party Software 22

Configure Performance Monitoring 23

Run Automated Deploy 23

Run Automated Functional Testing 23

Run Automated Load Tests 23

Document Solution Performance Baseline 24

The Execute Phase 24

Performance Factors 24

Performance Factors in 2004 24

Performance Factors in BizTalk 2006 26

BAM 26

Host Design 26

Orchestrations 26

Receive Ports 26

Send Ports 26

The Tracking Host 26

The Tracking Service 26

Delivery Notification 26

Correlation 26

Message Size 26

Flat File Processing 27

Business Rules Engine 27

Performance Metrics 27

BizTalk Performance Metrics 27

SQL Server Performance Metrics 27

Windows Server 2003 Performance Metrics 28

IIS 6.0 Performance Metrics 28

ASP.Net Performance Metrics 28

Performance Bottlenecks 28

High-Level BizTalk System Bottlenecks 28

Items to Check First 29

Processing Host Queues 29

Specific Types of Performance Bottlenecks 29

Disk I/O Bottlenecks

CPU Bottlenecks

Memory Bottlenecks

Network I/O Bottlenecks

Database Contention Bottlenecks

MaxConnections Causing Bottlenecks

Thread Starvation Bottlenecks

Large Message Size Bottlenecks

XML Bottlenecks

Pipeline Bottlenecks

Tracking Bottlenecks

ASP.Net Bottlenecks

Errors and Exceptions Causing Bottlenecks

HTTP Bottlenecks

SOAP and Web Services Bottlenecks

MQ Series Bottlenecks

Throttling Bottlenecks

MaxReceiveInterval as Related to Latency and Bottlenecks 66

Useful Tools and How to Use Them 67

PerfMon 67

Tracelog.exe 67

Logman.exe 67

Log Parser 67

PALS 67

Performance Log Viewer 1.6 (toolbox) 67

SQLIO 67

Where to Obtain SQLIO 67

How to "Quickly" Use SQLIO 67

SQLIO Resources 67

SQLIOSIM 68

When To Use SQLIO vs. SQLIOSIM 68

Log Parser 2.2 68

RDCMan (toolbox) 69

Where to Obtain RDCMan 70

How to "Quickly" Use RDCMan 70

RDCMan resources 70

The F1 Profiler 70

PerfConsole 70

PowerShell Scripts Which Make use of These Tools 70

Engagement Documentation Examples

Biztalk Performance Lab Delivery Guide - Performance Lab Process - The Scope Phase

robsteel — Tue, 26 Jun 2007 19:23:00 GMT

The Scope Phase

This section will include sub-sections that discuss considerations for conducting the Scope phase of the Performance Lab Process.

Why Consider Scope?

A common mistake, all too often made, is to underestimate the scope for a Performance Lab Engagement. It is very unlikely that a team can build an entire production-like environment and completely test a complex production system in only a few weeks. Failing to realize this can doom a Performance Lab Engagement to failure before it even starts.

A team should pick battles carefully. In a Performance Lab only scheduled to last a few weeks at the most, the team should be laser focused on one or two, maybe three at most, key performance issues. The application to be tested should be specifically developed to focus on the key areas of focus and should factor out all other technology variables as much as possible.

Occasionally, the organization requesting the performance lab simply will not understand the performance characteristics of their BizTalk solution enough to provide input into the Performance Lab Engagement. In this scenario, the best approach is often to make the first engagement’s objective to understand the basic performance of the various parts of the solution. Additional Lab Engagements can be scheduled to go into more detail.

A Document Engagement Summary

After it has been determined that a Performance Lab Engagement should take place, it is critically important to document certain specific details about the engagement as quickly as possible. Ideally, this can be done as agenda items during the initial meeting or call. One reason is to ensure that all stakeholders agree on the Engagement Details. Another reason to get details in words is because many assumptions need to be made based upon specific details about hardware, software, goals, etc. A lack of communication or an assumption that doesn’t hold can cause ill will and possibly even cause a Lab Engagement to fail or be abandoned.

Later in this guide, there is a section about Engagement Documentation. Many of the steps and tasks in the Performance Lab Engagement Process involve creating content for various sections of the Performance Lab Engagement Document. Creating and updating sections of this document as the lab is conducted results in a much better a document than if the document is left as an afterthought.

During this step of the process, we want to complete content for all of the Executive Summary section of the Performance Lab Engagement Document, with the exception of the Summary of Results section:

Goals and Objectives Section of Document Engagement Summary

With all stakeholders involved, create from 1 to 5 unambiguous bullet points that clearly state the goals and objectives of the Performance Lab Engagement. These bullets will typically address one or more of the following topics:

· Throughput

o Ex. Achieve highest possible throughput with predefined solution constraints and optimal hardware

· Latency

· Peak Loads

· Time to Complete a batch of size x

· Recovery from floodgate situations

As a best practice, it is recommended that goals and objectives be stated in terms of “achive highest possible X given hardware and software contraints” as opposed to giving specific performance numbers as objectives.

It is also best to state exactly how goals and objectives will be measured. The best technique is to build the wording for how the goal is measured right into the goal itself. For example, “Maximum Sustainable Throughput of XX end-to-end as measured by the counter ‘XLang/s\orchestrations completed / second’”

Knowledge to Consider

Establishing Performance Criteria in MSDN

Terms and Concepts We Use in Patterns and Practices on Codeplex

How To: Identify Performance Testing Objectives

How To: Consolidate Various Types of Performance Requirements and Testing Objectives

How To: Coordinate Performance Testing With an Iteration Base Process

How To: Evaluate Systems to Improve Performance Testing Effectiveness

How To: Quantify End-User Response Time Goals

Roles and Responsibilities Section of Document Engagement Summary

Clearly documenting, at the start of the engagement, and obtaining agreement between all the stakeholders as to the specific roles and responsibilities of each party involved in the engagement is critical to success. Doing this step well can help a team avoid all manner of confusion and miscommunication.

Typical examples of Roles might include the following but each situation may require other roles:

· Customer

· Partners

· Consultants

· Software Vendors

· Hardware Vendors

· etc

Typical responsibilities might include the following, but each situation may require other responsibilities:

· Provide specific hardware

· Provide specific software

· Provide specific expertise

· Logistics

· Connectivity, especially if lab hardware is remote

· Provide Specific deliverables

o Application to be tested

o Automated build

o Automated Deploy

o Automated Load Tests

o Automated Load Generation

o Test Data

o Documentation

For examples of what might go into the Roles and Responsibility section, see the Engagement Documentation Section of this guide.

Engagement Timeline

A project plan or Gantt Chart is typically overkill for Performance Lab Engagements, at least in our experience, so we don’t create them. What is very helpful though is to create a timeline. Visio is especially good for this task using the Timeline template. An example of a timeline might appear as in the image below.

It is important to keep the timeline simple enough to be easily understood yet detailed enough to communicate milestones effectively. The Milestones that noted on the Time for a specific Performance Lab Engagement will vary with circumstances and customer requirements. The actual Milestones should be agreed upon by all stakeholders and reviewed regularly. One technique, which isn’t depicted in the image above, is to use color coding to indicate who is responsible for delivering each milestone. Indicating which roles are responsible for which milestones can add addition communication value to the timeline.

Knowledge to Consider

Integrating Visio 2007 and Project 2007

Integrating Visio 2007 and SharePoint Products and Technologies

Hardware Diagram

This section will discuss considerations for creating an initial description of the hardware stack, communicating those details to all stakeholders, and an example Hardware Diagram.

Why Create a High-Level Hardware Diagram

During the Scope phase of the project, the intention is to define the project, discover risks, and explore the feasibility of the engagement. One factor that is almost always an issue is hardware availability! Since this is such a critical issue, spending some time during the Scope Phase seems like and obvious good-practice. Even when hardware is available, it typically requires some lead time to be provisioned, imaged and generally made ready for the engagement. Don’t leave the hardware details too late in the project!

Example High-Level Hardware Diagam

In the image, an example of a High-Level Infrastructure or Hardware Diagram can be seen from an actual Performance Lab. There are many and perhaps better ways to create these diagrams but this is what we run with and it seems to effectively communicate the hardware needs at this phase of the project. What’s most important is the information communicated not the art used.

Hardware Information to Consider in the Scope Phase

· Machine Architecture (x86, x64, IA64, etc)

· Processors ( Type, Speed, How Many, cores, use of Hyper-threading )

· RAM ( Amount each machine )

· Local Disk Storage (type, size, speed)

· SAN ( Storage Requirements, How many LUNS, SAN card type )

· Network Cards (number in each machine, 100MBit vs. 1000MBit )

· Are firewalls present

· Is Network Load Balancing Hardware to be used

· Are specific machines to be clustered?

Software Information is also Useful!

· Operating System for each machine ( 32 or 64 bit, clustered or not, etc )

· Server Software to be installed on each machine

· Virtualization used if any (not typically used for a Performance Lab but will be more common in the future )

· Specific software features not typically installed like

High Level Architecture Diagram

Why Create a High-Level Architecture Diagram

In the Scope Phase of the process, we are always trying to discover risks. Once the Goals and Objectives are defined, it’s a good idea to learn as much as possible about the details regarding the design of the system, the features and technologies used by the system, the complexity of the system, etc. Depending of the circumstances of a particular engagement, the software solution may have varying amounts of documentation. At the very least, obtain from the customer a two or three pager showing basic information about the solution the parts of the system, the features of BizTalk Server Being Implemented, what other software technologies are part of the solution, how the system is divided into parts, etc.

Example High-Level Arch Diagram

I dream of a day when we’ll create extensions to the Visual Studio Distributed System Designers to make that tool more optimal for precisely modeling BizTalk Server solutions. Unfortunately, that day has not yet come. You can still use VSTS for Architects to produce some pretty good diagrams to explain and communicate the design of the solution to be tested during a Performance Lab Engagement. This task is typically either done by the customer or the vendor that developed the solution, and the output varies for every project. Fortunately the output isn’t as important as the shared understanding between the stakeholders that many different formats, documents and diagrams can convey.

At some point, I will create an example, but all the ones I have at this point were confidential to the customer.

Biztalk Performance Lab Delivery Guide - Performance Lab Process - Before the Process Begins

robsteel — Tue, 26 Jun 2007 19:15:00 GMT

Before the Process Begins

On the BizTalk Ranger Team, we have a triage process that we go through before we agree to do a particular engagement. This is needed because we typically have more requests to engage then we have time or resources. Even with unlimited resources, it is a best practice to do some critical thinking about details and expectations before agreeing to do an engagement. The specifics will vary according to the needs of each user of this guide. Consultants and other BizTalk professionals will certainly want to consider developing some set of criteria to determine when they will do a Performance Lab Engagement.

Some topics of a triage process could include the following;

· Goals and Objectives for the engagement

o Is the desired performance obtainable?

o What are the constraints on hardware and software

o Goals regarding throughput

o Goals for latency

· A brief detail of the scenarios to be tested

o What technologies are involved?

o What adapters are needed?

· Set expectations about what an engagement entails

· Responsibilities and deliverables for each party in the engagement

· Initial engagement timeline

· Etc.

BizTalk Performance Lab Delivery Guide TOC submitted for comment

robsteel — Tue, 26 Jun 2007 18:30:00 GMT

I have seen instances where others have used blogs to evolve published works into more useful and powerful assets. I like this idea because it gets the content to the users, via the blog, before the publication date. I also like the concept of getting as much feedback as possible. This blog will attempt to serve this purpose for my upcoming "BizTalk Performance Lab Delivery Guide". I'm hoping that readers in the community will be generous with their comments and constructive criticism regarding the structure and content of this document.

To begin this experiment…

Please find below, a top-level outline for content which I intend to publish through an as yet to be determined mechanism. Effectively the content will all be available via this blog for those who like blogs, but it will eventually end up as a downloadable document of some sort, probably on MSDN. I'd like to ask the community to comment on the taxonomy of this material as it currently exists so that I can tailor the structure and content as much as possible, ultimately increasing the value to the community.

If you feel strongly that something is missing, organized strangely, off-topic or otherwise less than it could be I very much appreciate your comments.

You will a list in the bar on the left with links to the sections of the document as they are posted. This strategy will hopefully allow for more collaboration then the typical temporal organization of a blog would provide. Each section will have a separate page and if sections get long, sub-sections will have pages

If anyone has a better ideas, they are very welcome, please comment.

The top-level outline for this content is currently as follows: I will modify and add top-line sections based upon feedback from the community. In my next post I will elaborate on the next level of this outline. You can click the links to go to each section or you can also get to them via the Tags list on the left column of this blog.

NOTE: BPLDG is an abbreviation for BizTalk Performance Lab Delivery Guide.

Useful Tools

Example Engagement Docs

BizTalk Performance Lab Delivery Guide - Specific Types of Performance Bottlenecks

robsteel — Tue, 26 Jun 2007 13:55:00 GMT

In this section, various types of Performance Bottlenecks will be discussed. For each type of Bottleneck we will include some information specific to that type of bottleneck. The following subsections will be included for each type of bottleneck.

You Might have a TypeX Bottleneck if…

Performance Counters

Isolation

Tuning Options

Some sections will have additional subsections

Disk I/O Bottlenecks

CPU Bottlenecks

Memory Bottlenecks

Network I/O Bottlenecks

Database Contention Bottlenecks

MaxConnections Bottlenecks

Thread Starvation Bottlenecks

Large Message Size Bottlenecks

XML Bottlenecks

Pipeline Bottlenecks

Tracking Bottlenecks

ASP.Net Bottlenecks

Errors and Exceptions Causing Bottlenecks

HTTP Bottlenecks

SOAP and Web Services Bottlenecks

MQ Series Bottlenecks

Throttling Bottlenecks

MaxReceiveInterval as Related to Latency and Bottlenecks

BizTalk Performance Lab Delivery Guide - High-Level BizTalk System Bottlenecks

robsteel — Tue, 26 Jun 2007 13:41:00 GMT

It is important when dealing with complex systems, which BizTalk solutions tend to be, to take a top down approach when attempting to isolate specific performance problems. Looking at the system as a whole, checking some ‘usual suspects’ and doing some initial tests can often save time and provide a methodical approach to deciding which specific bottleneck tests to conduct.

Items to Check First

Are Errors in the Event Logs?

Is The Tracking Host stopped?

Is the TDDS Service Running?

Is the ENTSSO Service Running on all BizTalk Servers?

Is SQL Server Agent Running?

SQL Server Jobs are disabled?

Processing Host Queues

If the ProcessingHostQ count (see the Perfmon counter table below) is climbing, it indicates that the orchestrations are not completing fast enough

BizTalk Performance Lab Delivery Guide - Performance Bottlenecks

robsteel — Tue, 26 Jun 2007 13:28:00 GMT

Conducting a performance lab is largely a matter of investigating and discovering the existence of various bottlenecks, then finding a way to resolve the bottleneck to allow for either more throughput or lower latency. In this section are descriptions of various types of performance bottlenecks as they relate to BizTalk Server solutions and some information about how to discover their existence and resolve them when possible.

Before delving into the specific guidance below, it is recommended that the reader digest the following sections from the product documentation

How to Investigate Bottlenecks

Identifying Bottlenecks in the BizTalk Tier

Identifying Bottlenecks in the Database Tier

Guidelines for Avoiding Bottlenecks

In the sections below, we will first discuss High-Level BizTalk System Bottlenecks and then we will get into discussions of Specific Types of Performance Bottlenecks.

High-Level BizTalk System Bottlenecks

It is important when dealing with complex systems, which BizTalk solutions tend to be, to take a top down approach when attempting to isolate specific performance problems. Looking at the system as a whole, checking some ‘usual suspects' and doing some initial tests can often save time and provide a methodical approach to deciding which specific bottleneck tests to conduct.

Specific Types of Performance Bottlenecks

You Might have a TypeX Bottleneck if...

This subsection will discuss the types of "software smells" and other indications that might lead someone to suspect each particular type of bottleneck.

Performance Counters

This subsection will discuss the specific Performance Counters used when investigating a particular bottleneck. This section will also include information about reasonable values, how counters relate to one another, etc.

Isolation

This subsection will include information and guidance for how to isolate the specific bottleneck to confirm it's existence.

Tuning Options

This section will include information and guidance for how to either remove the bottleneck or work around it.

Some sections will have additional subsections

Some types of bottlenecks will have additional subsystems as needed.

BizTalk Performance Lab Delivery Guide - Performance Metrics

robsteel — Mon, 25 Jun 2007 22:18:00 GMT

Performance Metrics

In this section we discuss the various performance metrics that you need to know before attempting to measure the performance of a BizTalk Solution. In later sections we will discuss specific performance counters and which counters to watch when looking for specific types of bottlenecks, so we do not do that here. Instead this section provides pointers to educate the reader regarding performance metrics for BizTalk Server 2006 and SQL Server 2005. This section is here to provide a reference for the user when more information is needed for a specific performance object or counter that might be mentioned later in this document. When you see

BizTalk Performance Metrics

For a detailed description of the performance counters available in BizTalk Server and to get information about counters mentioned in this document, see Performance Counters in MSDN

SQL Server Performance Metrics

Additionally, during a lab we spend time focused on SQL Server Performance counters. For a detailed description of the performance counters available in SQL Server 2005 and to get information about counters mentioned in this document, see Using SQL Server Objects in MSDN

See the following Links for a deeper understanding of SQL Server Performance

SQL Server 2005 Waits and Queues

Troubleshooting Performance Problems in SQL Server 2005

How to troubleshoot SQL Server performance issues

Tools for Performance Monitoring and Tuning

Windows Server 2003 Performance Metrics

IIS 6.0 Performance Metrics

ASP.Net Performance Metrics

BizTalk Performance Lab Delivery Guide - Performance Factors in BizTalk 2006

robsteel — Mon, 25 Jun 2007 22:03:00 GMT

In BizTalk Server 2006, new features were added and existing features were improved. While all of the performance factors mentioned in the "Performance Factors in BizTalk 2004" section are still valid in BizTalk Server 2006, some additional factors must be considered. The sections below discuss the additional factors that should be considered.