1. t Sponsors Johan Hedberg Integration MVP 10x latency improvement – how to squeeze performance out of your BizTalk solution BizTalk Summit 2015 – London ExCeL London | April 13th & 14th

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

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

4. Plan Do Check Act

5. DesignDevelopTestTune

6. Instrumentation

7. BizTalk Instrumentation DTA Built-in Perf-Counters BAM Custom Perf-Counters Trace & Log Statements Exception Handling

8. Facade Process Data The architecture

9. Consumer Facade Canonical Process Backend Provider

10. Cons Proc Back End Snd Rcv GetVechicleInformation

11. Snd Rcv Map to Canonical Snd Auth Snd Debit

12. Rcv EnrichMap Lookup color Snd Model Info Snd GetVechicleInformation

13. Snd Rcv Map from Canonical GetVechicleInformation

15. 16s

16. MsgBox

17. MsgBox hops 38

18. 38~300ms 11 s MsgBox delay

19. Optimization 1 Reduce MsgBox hops

20. Cons Proc Back End Snd Rcv GetVechicleInformation

21. Cons Proc Back End Snd Rcv Call GetVechicleInformation

22. Call Rcv Map to Canonical Snd Auth Snd Debit GetVechicleInformation

23. Called EnrichMap Lookup color Snd Model Info Call GetVechicleInformation

24. Snd Called Map from Canonical GetVechicleInformation

25. 22

26. 22~300ms 7 s

27. 10 s

29. Optimization 2 Consider your Level/Layer of re-use

31. Snd Rcv

32. Call

34. 10

35. 10~300ms 3 s

36. 5 s

38. Optimization 3 Use Caching

40. 4.4s

42. Optimization 4 Optimize your logical flow

43. Call Rcv Map to Canonical GetAuth Call Debit GetVechicleInformation

44. Call Rcv Map to Canonical GetAuth Call Debit Snd Resp GetVechicleInformation

45. 3.8s

46. Optimization 5 Consider your Host Settings

47. Host Separation Polling Interval ThreadingThrottling Memory Global Tracking

48. 2.2s 500 (~300) 50 (~30)

49. Optimization 6 Inline Sends

50. Cons Proc Back End Snd Rcv Call GetVechicleInformation

51. Cons Proc Back End Inline Send Rcv Call Code GetVechicleInformation

53. 1.9s

54. (Optimization 7) Instrumentation Where is the remaining time?

55. 1s 150 ms

56. 100 ms 150 ms

57. 1.0s

58. Optimization 8 Persistence Points.

59. Send Response Write To Trace “Orchestration Done” Long Running Scope Write To Trace “Scope Done” Non-Serializable 1 2 3 Atomic Scope

60. Send Response Write To Trace “Orchestration Done” Write To Trace “Scope Done” Code that does not need Transactions 1

61. 0.95s

62. x17x17.

63. 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!

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