High Performance Network Applications In The Capital Markets

pages

English

Documents

2013

Écrit par
Montgomery , Todd

Publié par
lettier

Lire

Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres

pages

English

Documents

2013

Lire

Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres

Publié par

lettier

Publié le

13 octobre 2013

Nombre de lectures

Licence :

En savoir +

Langue

English

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!

Voir

Publié par

lettier

Publié le

13 octobre 2013

Licence :

En savoir +

Langue

English

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

Market Data Growth Data Deluge

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

The Trader Why Latency Matters

FastMarket Data Ultra Messaging

INFA at 40.00

Slowarket Data M

TIBCO RV and EMS

Feed Handler

Starting Line

Execution

Got INFA at 40.00

Execution

You Lost!

Got INFA at 41.00

The Exchange Why Latency Matters

Trade

Acknowledge

Cancel

Exchanges

Alpha Ultra Messaging

You Both Lost!

(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!

Legacy Messaging Designs Before 2004

Daemon Based Design 6 Data Hops

Broker Based Design 4 Data Hops

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!

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

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

S Z

“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!

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

Voir