noam87

noam87

Hi, so I’m reading Elixir In Action and on page 159 it hints that spawning off concurrent processes is a code smell.

Scenario: User clicks button to generate a schedule -> a schedule is generated in the background -> an email task sends him an email with the schedule -> at the same time a db task converts this schedule into db-friendly format and stores it.

Approach 1: Have a bunch of long running servers, ScheduleServer, EmailServer, DbConverterServer, all waiting for messages to process in its inbox. User actions simply send a message.

Approach 2: Every time a user does one of these actions, I spawn off a new instance of ScheduleGenerator (which itself spawns the other processes that come after), so that each user request is done in parallel. When the task is complete, the process dies.

Which would be the “elixir way” to do this? What are some rules of thumb for when to choose one approach over the other?

Showing Posts 1 to 3

dom

dom

Approach 1 makes sense if schedules have to be processed in order. The point of the process then is to serialize the calls. Otherwise, it’s better not to go through one process, because it creates a potential bottleneck.

I would use a supervised task: http://elixir-lang.org/docs/stable/elixir/Task.html

jwarlander

jwarlander

Are you refer to the last part of the page?

“If you can’t make message handling fast enough, you can try to split the server into multiple processes, […] This should be your last resort, though. Parallelization isn’t a remedy for a poorly constructed algorithm.”

If so, I think he just means that exactly; start by optimizing the algorithm itself, making sure each single message is handled efficiently. Then, if the algorithm can meaningfully be parallelized, try to split into multiple processes if need be.

There are other reasons for concurrency, of course. Some things, like incoming web requests, are naturally concurrent. Other things may need the fault isolation that a separate process gives you.

If you were to make a game, for example, it’s quite likely each player’s input would be handled in a separate process. Any fault in the input handling code could then only crash that process, and wouldn’t affect any other player. For a game with room-based navigation, each room might be a process as well - players could affect the state of the room by dropping items, picking them up, maybe destroying things, etc. In this case as well, you’d benefit from the fault isolation; code execution that’s triggered in the room process only affects that room and it’s inhabitants. With the right monitors, crashes in either of those parts can be safely handled with minimal impact.

Email sending is probably a typical thing though where you need to limit concurrency with a pool, or just have a single persistent email sender process, depending on your scale.

sasajuric

sasajuric

Author of Elixir In Action

That’s certainly not what I meant to say :slight_smile: The paragraph you’re refering to just warns that if you’re optimizing a sequential piece of code, you should first consider algorithmic and technology-specific optimizations.

The reason I added that comment is because I’ve seen people frequently trying to optimize a suboptimal algorithm by running chunks in multiple processes. While that might improve performance, it is often better to first consider whether algorithm can be improved. For example, if you can reduce complexity from say polynomial to logarithmic, then you should get much better savings.

However processes should certainly be used to run different independent or loosely dependent things. Per your description, the output of e-mailing is not depending on storing to db, so you can do those two things in separate processes. This will not only improve efficiency (the VM might run those things in parallel), but also fault-tolerance (if e-mailing fails, storing to db might still succeed).

When it comes to your question, I agree with @dom’s response. You need a long-running server only if it needs to keep some state or if actions need to be serialized.

— All posts loaded —

Where Next? Top

Trending in Questions Top

RSP87
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
RemyXRenard
I’m seeing that a list inside a Kino.DataTable will be interpreted as a charlist, even if the Kino.configure() is set to charlists: :as_l...
New
velrest
So my question is quite simple and i have found no conclusive answer on forum, google or AI. Should we use :erlang.float for Integer to ...
New
nseaSeb
Hello, I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
samoloth
Hi, I’ve just set up an application with ash_authentication. There is only magic link strategy for now, so there is no confirmation add o...
New
FlyingNoodle
If a change or preparation module uses Ash.Changeset.get_argument/2 or Ash.Query.get_argument/2 (or any of the other get_argument functio...
New
ryanwinchester
apply_graft/2 doesn’t rewrite an add_many sub-workflow’s deps on an add step. Grafted jobs cancel with “upstream job was deleted” Version...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve. They are GUI (Emerge) and State management (S...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews