High Performance Network Applications In The Capital Markets

Montgomery, Todd

Description

High Performance Network Applications in the Capital Markets Todd L. Montgomery VP Architecture, Messaging Business Unit @toddlmontgomery 1 Why do Developers use Messaging? Message-Oriented Middleware (MOM) • Abstraction (Pub-Sub, Req/Resp, Queuing) • Separate physical systems from communication • Easily modify logic and scale applications • Functionality • Guaranteed delivery, fault tolerance, load balancing… • Efficiency • Well designed messaging systems reduce infrastructure • Leverage broad, deep and detailed expertise • Focus on core competencies, Faster Time-to-Market 2 Market Data Growth Data Deluge Aggregated One Minute Peak Messages Per Second Rates 7,174 Arca, CTS, CQS, OPRA, NQDS (in thousands) 5,957 > 1Terabyte of Data per Day 4,380 3,410 Total 2,562 Options Equities 1,925 1,562 1,100 696 559160 310120 265 7 10 13 3 Dec-00 Dec-01 Dec-02 Dec-03 Dec-04 Dec-05 Dec-06 Dec-07 Dec-08 Dec-09 Dec-10 Dec-11 The Trader Why Latency Matters Market Data Feed Handler Execution Fast Ultra Messaging Got INFA at 40.00 INFA at 40.00 Market Data Feed Handler Execution Slow You Lost! TIBCO RV and EMS Got Starting Line INFA at 41.00 4 The Exchange Why Latency Matters Exchanges Alpha Order Ultra Messaging Tango Trader Acknowledge TIBCO RV / EMS You Both Lost! Hotel Cancel Homegrown 5 (Ultra) Low Latency Timeline Race to Zero – Less than 8 years, 10,000x-100,000x decrease!

Informations

• Publié par: lettier
• Publié le: 13 octobre 2013
• Nombre de lectures: 29
• Licence : En savoir +
  Paternité, pas d'utilisation commerciale, partage des conditions initiales à l'identique
• Langue: English

Extrait

1

High Performance Network Applications in the Capital Markets 

Todd L. Montgomery VP Architecture, Messaging Business Unit @toddlmontgomery 

Why do Developers use Messaging? Message-Oriented Middleware (MOM) 

•

•

•

•

Abstraction (Pub-Sub, Req/Resp, Queuing) •Separate physical systems from communication •Easily modify logic and scale applications

Functionality •Guaranteed delivery, fault tolerance, load balancing… 

Efficiency •Well designed

messaging systems reduce infrastructure

Leverage broad, deep and detailed expertise •Focus on core competencies, Faster Time-to-Market

2 

Market Data Growth Data Deluge 

Aggregated One Minute PeakMessages Per SecondRates Arca, CTS, CQS, OPRA, NQDS (inthousands)   > 1Terabyte of Data per Day

3

The Trader Why Latency Matters 

Fast Market Data Ultra Messaging

INFA at 40.00

Slow arket Data M

TIBCO RV and EMS

Feed Handler

Feed Handler

Starting Line

Execution 

Got INFA at 40.00

Execution 

You Lost!

Got INFA at 41.00

4

The Exchange Why Latency Matters 

Trade

Acknowledge

Cancel

Exchanges

Alpha   Ultra Messaging

You Both Lost!

5

(Ultra) Low Latency Timeline Race to Zero–Less than 8 years, 10,000x-100,000x decrease! 

4-5 ms

200μs 

10μs 

≤2003 2004 (Ethernet) (Ethernet) Application

2μs 

<400 ns

   

2008 2010  2010 (IB) (10G,IB)  (IPC) to Application Latency

Predictions–Technology •<1μsEth (2012) •<500 ns Eth (2015) •<100 ns Eth (2020)

Predictions–Technique •<100 ns IPC (2012) •1G mps ITC (2012)

<50 ns

2011 (ITC)

IPC/ITC only Limited by CPU!

6

Legacy Messaging Designs Before 2004 

Daemon Based Design 6 Data Hops

Broker Based Design 4 Data Hops

7

2004–Need for a State Change More Efficient, More Scalable, More MORE… 

•

•

Motivations / Challenges •Systems not scaling to todays (yet alone tomorrows!) demands •Systems not resilient to failure •Trends:  •Need Efficiency, Need Consolidation, More with Less, Need Competitive Advantage (No Vendor Innovation)

Broker-based Solutions are a Bottleneck •source of contention that limits scalingBroker is a •Broker failure disastrous to latency and stability

Remove the Broker from the Message Path!

8

Shared Nothing Messaging MOM for Todays Demands 

•

•

•

Peer-to-Peer Messaging •No broker, No daemons •Direct connectivity between

sources and receivers

Parallel Persistence •message path and off to the sideBroker out of •Broker consulted only for recovery •Evolution of Queuing

Single Messaging API across all Use Cases •Source-based (vs. Immediate), Event Driven •No need for separate Queuing (or PTP) API

9

Topic Resolution Connecting Sources and Receivers (Peer-to-Peer) 

S Z

R X

R X

S Z

S Y

S X

 

R Y

“Service” Location Paradigms  •Static–manual, difficult scaling with topics •revreS edas-b–(non)caching variants •Multicast–(un)reliable variants

Traditionally, brokers handled the task of providing transparent connectivity between sources and receivers

Separatethe message delivery path and the topic discovery mechanism!

Avoid including topic string in each message!

10

Data Transport Choices Customization of Connectivity 

•

•

Transport Types– No One Size Fits All! •Unicast(Optimize for single receivers) •TCP (with varying buffering behaviors), Reliable Unicast (without   congestion control) •Multicast(Optimize for multiple receivers) •(Un)Reliable Multicast (NAK-based) •Intra-Host(Optimize for lowest latency) •IPC (Shared Memory), Inter-Thread (ITC)

Source Configuration •Runtime choice

11