Giter Club home page Giter Club logo

transaction-processor's Introduction

Transaction processor

This project is an example of using tokio multi-threading runtime to execute transactions over multiple accounts, concurrently. More on the components that made up the transaction processor can be found under design.md.

Build

The project can be built by using cargo build, using rust 1.55.0. It is built at the same time as a library and binary.

Processing transactions

Running the binary, that processes a set of transactions described in a regular text file, on local filesystem, can be done by: cargo run -- <filename path relative to cargo project root>. The binary output is a set of accounts, printed line by line, with respect to the schema client,available,held,total,locked.

Testing

Running the unit tests can be done by cargo test. The test are covering all the units of the project, except for the ones from the logger module and the drill orphan function, present in transaction module, which is exercised mainly in integration context, during the benchmarks tests and put out for manipulating the tokio asynchronous runtime and the abstractions introduced by the project.

Coverage

Coverage was computed by running cargo kcov. The details on coverage can be found in coverage.json.

Benchmarks

The purpose of the existing implemented benchmarks are exercising the transaction processing in terms of scalability and asynchronous multi-threaded runtime. Two performance tests were separated in two groups:

  • small-inputs
  • large-inputs

The transaction used for the benchmarks is deposit and the assumption is that all transaction types have the same cost, so it does not matter what type of transaction we use to showcase the scalability and multi-threaded runtime at action. In order to really make use of the multi-threaded environment in a setup that does not involve millions of transactions, the transaction execution supports interfering into the execution of a transaction, by delaying it with a 100 millis for every executed transaction. This enables greater contention on system resources, in the period of time the transaction is delayed, because the transaction processor wants to fulfil other transaction at the same time.

Running all the benchmarks can be done by: cargo bench. Benchmarks run on a Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz, with a 16 cores CPU, can be found bellow:

transaction-processor's People

Contributors

iulianbarbu avatar

Watchers

 avatar  avatar

transaction-processor's Issues

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.