https://github.com/adroll/spillway

An Erlang OTP application for load shedding
https://github.com/adroll/spillway

erlang hacktoberfest

Last synced: 2 days ago
JSON representation

An Erlang OTP application for load shedding

• Host: GitHub
• URL: https://github.com/adroll/spillway
• Owner: AdRoll
• License: mit
• Created: 2018-07-11T18:48:04.000Z (over 6 years ago)
• Default Branch: main
• Last Pushed: 2024-07-01T00:15:07.000Z (6 months ago)
• Last Synced: 2024-12-16T16:31:22.733Z (10 days ago)
• Topics: erlang, hacktoberfest
• Language: Erlang
• Homepage: https://hex.pm/packages/spillway
• Size: 67.4 KB
• Stars: 27
• Watchers: 14
• Forks: 3
• Open Issues: 1
• Metadata Files:
  • Readme: README.md
  • Changelog: CHANGELOG.md
  • License: LICENSE

Awesome Lists containing this project

README

        
Overview

--------------

Spillway is an Erlang OTP application used for load shedding. The idea behind spillway is to use it

to be able to limit the number of in flight concurrent calls to a section of code.

Some examples:

 - As a server you can use spillway to limit the number of concurrent running requests to a service. You can

 determine when to throw away some requests by considering each request type and its weight.

 A request weight is measured by the cost fo performing the work (CPU/MEMORY) and the cost to not perform

 the work (BUSSINESS IMPACT).

 - As a client, when you face a failing server you might choose to retry a request. Spillway will let you

 implement a simple controlled-in-size-buffer mechanism that will allow you to retry some of the requests without

 running out of memory or resources.

Example of use

----------------

A process about to execute a named section of code whose maximum parallelism

should be limited will call spillway:enter/2/3 with the name, the weight, and limit.

If the return value is the 2-tuple {true, TotalWeight}, the process may enter the section of code

 (there now being TotalWeight in use concurrently-executing accesses), and otherwise not.

If the process entered the section of code, it should call spillway:leave/2 with the name and weight

after completion.

No special arrangement is made to handle process exits.  If a process dies without

calling spillway:leave/1, the counter will be inaccurate.  This is intentional,

and callers should make arrangements to mitigate this occurrence.

```

case spillway:enter(running_requests, Weight, Limit) of

 {true, Value} ->

        try

           continue_executing(Something);

        after

            spillway:leave(running_requests, Weight)

        end;

 false ->

     discard(Something)

end.

```

Setup

-------

- Add the application to your rebar3 dependencies and start the application normally.

Alternatively you can also attach the supervision tree directly to the main supervisor of your

application.

Implementation

----------------

Spillway is implemented based on ETS-based bounded named counters.

Build

-----

  $ make

  $ make ct

1.x Changelog

-------------

1.1 2018-07-13

 * Remove the need to initialize counters

1.0.0 2018-07-11

 * Add initial implementation