Scaling For (Almost) Free

Slides:



Advertisements
Similar presentations
1 Perspectives from Operating a Large Scale Website Dennis Lee VP Technical Operations, Marchex.
Advertisements

COMPUTER NETWORK TOPOLOGIES
MINJAE HWANG THAWAN KOOBURAT CS758 CLASS PROJECT FALL 2009 Extending Task-based Programming Model beyond Shared-memory Systems.
Thomas Arts Industrial Use of a Functional Language Thomas Arts Ericsson Computer Science Laboratory Stockholm, Sweden
Dr. Kalpakis CMSC 621, Advanced Operating Systems. Fall 2003 URL: Distributed System Architectures.
Spark: Cluster Computing with Working Sets
490dp Synchronous vs. Asynchronous Invocation Robert Grimm.
Registered Processes A perennial problem in client-server computing is “How do clients find the server?” Two possible answers:  Clients are told about.
Erlang concurrency. Where were we? Finished talking about sequential Erlang Left with two questions  retry – not an issue; I mis-read the statement in.
Server Architecture Models Operating Systems Hebrew University Spring 2004.
Lecture 8 Epidemic communication, Server implementation.
Loupe /loop/ noun a magnifying glass used by jewelers to reveal flaws in gems. a logging and error management tool used by.NET teams to reveal flaws in.
Fundamentals of Python: From First Programs Through Data Structures
BINA RAMAMURTHY UNIVERSITY AT BUFFALO System Structure and Process Model 5/30/2013 Amrita-UB-MSES
The hybird approach to programming clusters of multi-core architetures.
CSE 486/586 CSE 486/586 Distributed Systems PA Best Practices Steve Ko Computer Sciences and Engineering University at Buffalo.
U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Computer Systems Principles Processes & Threads Emery Berger and Mark Corner University.
Block1 Wrapping Your Nugget Around Distributed Processing.
Concurrent Programming. Concurrency  Concurrency means for a program to have multiple paths of execution running at (almost) the same time. Examples:
U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Computer Systems Principles Concurrency Patterns Emery Berger and Mark Corner University.
Server to Server Communication Redis as an enabler Orion Free
Distributed System Concepts and Architectures 2.3 Services Fall 2011 Student: Fan Bai
CS 326: Functional Programming 1. 2 Erlang – A survey of the language & applications Paper by: Joe Armstrong, Computer Science Laboratory, Ericsson Telecom.
A Dynamic Operating System for Sensor Nodes Chih-Chieh Han, Ram Kumar, Roy Shea, Eddie Kohler, Mani, Srivastava, MobiSys ‘05 Oct., 2009 발표자 : 김영선, 윤상열.
Lecture 4 Page 1 CS 111 Online Modularity and Virtualization CS 111 On-Line MS Program Operating Systems Peter Reiher.
Streaming Applications for Robots with Real Time QoS Oct Supun Kamburugamuve Indiana University.
Page 1 2P13 Week 1. Page 2 Page 3 Page 4 Page 5.
Distributed Computing & Embedded Systems Chapter 4: Remote Method Invocation Dr. Umair Ali Khan.
Making Fault-Tolerance a Reality `
Failing gracefully With the actor model Roger Johansson
Presented by: Daniel Taylor
Advanced Operating Systems CIS 720
SEDA: An Architecture for Scalable, Well-Conditioned Internet Services
Threads vs. Events SEDA – An Event Model 5204 – Operating Systems.
Design Components are Code Components
CSE 775 – Distributed Objects Submitted by: Arpit Kothari
Applying Control Theory to Stream Processing Systems
CS240: Advanced Programming Concepts
Task Scheduling for Multicore CPUs and NUMA Systems
Swapping Segmented paging allows us to have non-contiguous allocations
New trends in parallel computing
Threads and Cooperation
System Structure and Process Model
System Structure and Process Model
System Structure B. Ramamurthy.
CSE 451: Operating Systems Winter 2006 Module 20 Remote Procedure Call (RPC) Ed Lazowska Allen Center
Topics Introduction to File Input and Output
Changing thread semantics
Transactional Memory Semaphores, monitors, and conditional critical regions all suffer from limitations based on lock semantics Naïve synchronization may.
System Structure and Process Model
CSE 451: Operating Systems Winter 2007 Module 20 Remote Procedure Call (RPC) Ed Lazowska Allen Center
Lecture Topics: 11/1 General Operating System Concepts Processes
Process Description and Control
CSE 451: Operating Systems Winter 2004 Module 19 Remote Procedure Call (RPC) Ed Lazowska Allen Center
Design Components are Code Components
CSE 451: Operating Systems Spring 2012 Module 22 Remote Procedure Call (RPC) Ed Lazowska Allen Center
CSE 451: Operating Systems Autumn 2009 Module 21 Remote Procedure Call (RPC) Ed Lazowska Allen Center
Prof. Leonardo Mostarda University of Camerino
Process Description and Control
Concurrency, Processes and Threads
Computer Science 312 Concurrent Programming I Processes and Messages 1.
Concurrency: Processes CSE 333 Summer 2018
Myrinet 2Gbps Networks (
Outline Chapter 2 (cont) Chapter 3: Processes Virtual machines
CSE 451: Operating Systems Autumn 2010 Module 21 Remote Procedure Call (RPC) Ed Lazowska Allen Center
Outline Chapter 3: Processes Chapter 4: Threads So far - Next -
Chapter 3: Process Concept
Johan Lindberg, inRiver
CSE 451: Operating Systems Messaging and Remote Procedure Call (RPC)
Threads CSE 2431: Introduction to Operating Systems
Presentation transcript:

Scaling For (Almost) Free Elixir: It’s a Process ❦ Aaron Seigo aseigo@mykolab.com

“Big whirls have little whirls, That feed on their velocity; And little whirls have lesser whirls, And so on to viscosity.” ― Lewis Fry Richardson

To take full advantage of Elixir programs need to be created with concurrency in mind.

Processes are the key mechanic Processes are shared-nothing execution contexts which are preemptively scheduled across a set of OS threads They are intrinsically capable of being run concurrently

Combine them into larger ones Distribute them across compute resources Write small programs Combine them into larger ones Distribute them across compute resources Run the small programs concurrently Erlang was way ahead of the micro-service bandwagon!

“We do not have ONE web-server handling 2 millions sessions. We have 2 million webservers handling one session each.” – Joe Armstrong “Managing Two Million Webservers”

Concurrent ≆ Parallel

Anatomy of a process Message Box Working Memory Code Path

Message passing ties the small programs into bigger ones The Message Box Processes may receive arbitrary messages Incoming messages are stored in the process’ inbox Messages are filtered using pattern matching Message passing ties the small programs into bigger ones

Enforces separation, simplifies management Workset Memory Each process has its own block of RAM Garbage collection hides most of the details When a process is done, its memory is reaped 0(1) Enforces separation, simplifies management

Defines the mechanism and lifespan of the process Execution Stack Modules are the unit of code organization (topic) Processes are the unit of code execution (purpose) When the code halts or errors, the process exits Defines the mechanism and lifespan of the process

Processes Work Together Message Passing API Separation of Concerns Modularity Lifespan Tracking Reliability

Message Passing send receiver, message

Message Passing send receiver, message Posts the message to the receiver’s inbox and returns immediately. The message is also send’s return value.

Message Passing send receiver, message May be a pid, an atom that maps to a named process, a tuple {atom, node} to reach a named process on a specific node, or a Port that is connected to an external program.

Message Passing send receiver, message Can be anything. Literally, anything. Be curious and daring, but also careful with that power.

Message Passing f = fn -> "You just ran my code" end send self(), { :func, f } receive do { :func, g } -> g.() end

Message Passing receive do pattern → code end

Message Passing receive do pattern_a → code pattern_b → code end

Message Passing receive do pattern_a → code pattern_b → code _ → default mode end

Message Passing receive do pattern_a → code pattern_b → code _ → default mode after timeout → code end

Message Passing def loop do receive do pattern_a → do_a(); loop pattern_b → do_b(); loop _ → :unexpected_message after timeout → :timeout end

Message Passing def loop state do receive do pattern_a → state |> do_a |> loop pattern_b → state |> do_b |> loop _ → :unexpected_message after timeout → :timeout end

Message Passing

Separation of Concerns OOP : Object :: Elixir : Process Thanks to the shared-nothing* design processes are isolated from each other, making them perfectly suited to representing instance-specific data and actions. * there are exceptions, but they are well-hidden details

Elixir’s Big Brother Plan: linking and monitoring Lifespan Tracking Elixir’s Big Brother Plan: linking and monitoring Linking connects one process to another, so if the process exits abnormally the linked process will also crash. Monitoring, via the :trap_exit process flag, allows handling of those events instead of crashing.

Supervisor.start_link(children, options) Lifespan Tracking Supervisor.start_link(children, options) Supervisors are processes that watch over other processes, called their children, and automatically take action on failure. Since supervisors are processes, supervisors may supervise other supervisors. This is called a supervision tree.

Supervisor.start_link(children, options) Lifespan Tracking Supervisor.start_link(children, options) This allows systems to be robust and predictable in cases of failure. Which in turn means failure is something that can be embraced and used as a tool.

Supervisor.start_link(children, strategy) Lifespan Tracking Supervisor.start_link(children, strategy) Children are a list of function specifications that the supervisor will start and then monitor. {child_id, {module, atom, [term]}, restart, shutdown, worker, modules}

Supervisor.start_link(children, options) Lifespan Tracking Supervisor.start_link(children, options) Options are used to define: name start/restart limits (no. of attempts, max time to wait) management strategy

Supervisor.start_link(children, strategy: strategy) Lifespan Tracking Supervisor.start_link(children, strategy: strategy) :one_for_one: → just restart failures :one_for_all → restart all children on any failure :rest_for_one → restart all started after the failing process :simple_one_for_one → one child template, spawn on demand

Supervisor.start_link(children, options) Lifespan Tracking Supervisor.start_link(children, options) Moral of our story: just use Supervisor, don’t try and roll your own. There is nothing to add, only bugs to write.

Challenges and Caveats Throughput traded for latency Non-deterministic order of process execution Reliability and message passing in an imperfect world Bottlenecks Shared resources Shared state

live demo → seeing it in action, or tempting fate?

live demo → 1. Processes

live demo → 2. Messages

live demo → 3. GenServer

live demo → 4. Supervisor

live demo → 5. UnreliableTask

live demo → 6. Cluster

Breaking large problems into little ones Flavors of process: State Tasks Workers Resources Supervisors Elixir programs are a collection of flavored processes

Fun stuff to play with Pipelines → https://github.com/elixir-lang/gen_stage Parallel Streams → https://github.com/elixir-lang/flow PubSub → https://github.com/phoenixframework/phoenix_pubsub Easy Services → https://github.com/pragdave/jeeves Pools → https://github.com/devinus/poolboy Circuit breaking → https://github.com/jlouis/fuse Rate limiting → https://github.com/grempe/ex_rated Tracing → https://github.com/liveforeverx/exrun

Q&A go forth and make awesome things