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
Top Related