tSponsors

Johan HedbergIntegration MVP

10x latency improvement – how to squeeze

performance out of your BizTalk solution

BizTalk Summit 2015 – LondonExCeL London | April 13th & 14th

Who am I?

• Johan Hedberg

• MVP, former MCT and V-TSP

• Author

• Currently working as a solution architect for an information services (non-consultancy, non-Microsoft partner) company called Bisnode

• Twitter: @johhed

• http://blogical.se/blogs/johan

• dsf

Goal

• The goal originally: BizTalk performance

• The goal became: Design your BizTalk solution for performance

• The goal focus is: Design your BizTalk orchestrations for performance

• Some things to think about when planning your architecture to meet to your performance requirements

Plan

Do

Check

Act

Design

Develop

Test

Tune

Instrumentation

BizTalk Instrumentation

DTABuilt-in

Perf-CountersBAM

CustomPerf-Counters

Trace & Log Statements

Exception Handling

Facade

Process

Data

The architecture

Consumer Facade

Canonical Process

Backend Provider

Cons

ProcBackEnd

Snd

Rcv

GetVechicleInformation

Snd

Rcv

GetVechicleInformation

Map toCanonical

SndAuth

SndDebit

Rcv

EnrichMap

Lookup color

SndModel

InfoSnd

GetVechicleInformation

Snd

Rcv

Map fromCanonical

GetVechicleInformation

GetVechicleInformation

GetVechicleInformation

16s

MsgBox

MsgBox hops

38

38 ~300ms

11 s

MsgBox delay

Optimization 1Reduce MsgBox hops

Cons

ProcBackEnd

Snd

Rcv

GetVechicleInformation

Cons

ProcBackEnd

Snd

Rcv

Call

Call

GetVechicleInformation

Call

Rcv

Map toCanonical

SndAuth

SndDebit

GetVechicleInformation

Called

EnrichMap

Lookup color

SndModel

InfoCall

GetVechicleInformation

Snd

Called

Map fromCanonical

GetVechicleInformation

22

22 ~300ms

7 s

10 s

Optimization 2Consider your Level/Layer of re-use

Snd SndRcv Rcv

Call

Call

10

10 ~300ms

3 s

5 s

Optimization 3Use Caching

4.4s

Optimization 4Optimize your logical flow

Call

Rcv

Map toCanonical

GetAuth

Call Debit

GetVechicleInformation

Call

Rcv

Map toCanonical

GetAuth

Call Debit

SndResp

GetVechicleInformation

3.8s

Optimization 5Consider your Host Settings

Host Separation

Polling Interval

Threading Throttling

MemoryGlobal

Tracking

2.2s

500 (~300)

50 (~30)

Optimization 6Inline Sends

Cons

ProcBackEnd

Snd

Rcv

Call

Call

GetVechicleInformation

Cons

ProcBackEnd

InlineSend

Rcv

Call

Call

Code

GetVechicleInformation

1.9s

(Optimization 7)Instrumentation

Where is the remaining time?

1s150ms

100ms

150ms

1.0s

Optimization 8Persistence Points

.

Send Response

Write To Trace“Orchestration Done”

Long Running Scope

Write To Trace“Scope Done”

Non-Serializable

1

2

3

Atomic Scope

Send Response

Write To Trace“Orchestration Done”

Write To Trace“Scope Done”

Code that does not need Transactions

1

0.95s

x17

.

Summary• Create an architecture meets your requirements

• Instrument your solution

• Reduce MsgBox hops

• Choose an appropriate layer design

• Choose an appropriate layer of reuse

• Apply caching where possible

• Optimize your logical flow (order of shapes)

• Configure your host settings and polling interval

• Make use of Inline Sends

• Identity downstream backend issues and work to resolve them

• Reduce your persistence points by making appropriate use of scopes, transactions and trace statements

• Apply other techniques as needed to achieve your requirements!

Conclusion• No one size fits all – know your solution – know your requirements

• There are best practices…

• …and then there are “practices”

• Develop, test, tune, choose one thing. Repeat.

• How you optimize your solution alters the its demand on resources• Ie – inline sends will stop persistence, stop dehydration, consume more memory, hold on to

more threads longer – aka move demand from disk to memory and threads – configure accordingly… No solution is static.

• Applying the right optimizations to your scenario can give you a 10x latency improvement