High Performance Network Applications In The Capital Markets
23 pages
English

High Performance Network Applications In The Capital Markets

-

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

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!

Sujets

Informations

Publié par
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

Exrait

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 
FastMarket Data Ultra Messaging
INFA at 40.00
Slowarket 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 ZeroLess 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
PredictionsTechnology <1μsEth (2012) <500 ns Eth (2015) <100 ns Eth (2020)
PredictionsTechnique <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
2004Need 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) 
SZ
RX
RX
S Z
SY
SX
 
RY
“Service” Location Paradigms Staticmanual, 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
  • Accueil Accueil
  • Univers Univers
  • Ebooks Ebooks
  • Livres audio Livres audio
  • Presse Presse
  • BD BD
  • Documents Documents