• Save
BAXTER PoC
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

BAXTER PoC

on

  • 219 views

Proof of Concept for HFT PriceEngine Architecture

Proof of Concept for HFT PriceEngine Architecture

Statistics

Views

Total Views
219
Views on SlideShare
219
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

BAXTER PoC Presentation Transcript

  • 1. BAXTER PRICE ENGINEPROOF-OF CONCEPT REVIEWTimirKariaandJimMarino
  • 2. HighlightsAverage latency0.146973 milliseconds per message (146,973.09 nanoseconds) with no JVM tuningover 100,000 price samples (~6 million (6x106) messages / minute)What are timings based upon?Receive a byte array representing a price, deserialize it, validate, cache, apply 100 internalprice rungs on 1 ladder, apply 100 external price rungs on 3 external margin groups, andserialize the results for delivery to an order entry system.Machine: (PEPOC2 in BUD)Dell PowerEdge R200Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz4GB RAM4GB RAMComplexityLines of code: ~1400XS Structural Complexity rating (Structure 101): 0
  • 3. Core Processing Logic PrinciplesPrice Calculations – design of price structurePrice objects are built as the move through the systemPrices should not contain more information than required at any givenpointMinimize functionality and focus on data in pricesPrice objects get larger (more complex) as they contain more informationbut are eventually condensed into a quoteThe relationship between prices should be easy to understand and simpleto implementTangled business logic can be implemented in processing logic rather thanin priceFast serialization/de-serialization of objects is mandatoryWe used Google Protocol Buffers for speed but could equally use JMS oranother transport layer
  • 4. Architecture Performance PrinciplesFirst rule of distributed applications: Don’tCollocate as much as possiblePerformanceAvoid network overheadAvoid serialization (time consuming, excessive object creation)SimplificationCode, configuration, monitoring, and managementUse lock-free CAS operations where possibleAvoid contentionSeparate mutable and immutable dataShare immutable objectsReduce unnecessary object creationLimit system jitter and latency from GC cyclesPrice objects are only updated by a single threadNo synchronization, less complexity
  • 5. Architecture ModularityGoalsEnforce separation of concerns between subsystemsAll subsystems communicate via an APISubsystem implementation classes and artifacts are not visible outside of theirmoduleAbility to replace subsystemsExtraction, internal pricing, external pricing, distributionArchitected extension pointsDefined SPI for extending the Price EngineAllow customers to modify default behaviorsTransport independence – use JMS, ZeroMQ, other transport layer, without codechangesNo significant runtime performance impactSmall startup impact for classloading due to OSGi filters
  • 6. How prices work
  • 7. Data ModelData Model predicated on simplicity, flexibility and matchingbusiness flowObject hierarchy simplified into manageable hierarchy that isstill flexibleAdheres to the following principlesOnly carry the data you needUse primitive types when availableKeep objects and dumb containers for data as much as possibleMinimize network object sizeE.g. incoming prices are 55 bytes
  • 8. Architecture
  • 9. FlowsSystem architecture built on a series of Flows that contain 1..NProcessors which operate on a Price in a given orderA module contains one or more flowsThe terminating Processer in a Flow calls the next FlowFlows are synchronousAvoid context switching, threading overhead, and need to synchronizeprice objectsOnly one thread modifies a price objectSimplify programmingAsynchronous programming more complexSystem is multi-threadedA flow may be running on multiple threadsCan spin-off async tasks and delivery intermediate data as necessary
  • 10. Flows and Modules
  • 11. ProductivityDesigned as a Maven multi-module project● Zero-configuration setup: git clone… mvn clean installAutomated integration testing● Full end-to-end in-container system testing as part of localMaven build● Can be run as part of a CI buildIntegrated Caliper microbenchmark framework● http://code.google.com/p/caliper/