Home>
Overview

What is the reason why Elixir + Phoenix is ​​quick?
Can it be considered as a language that has great synergies that it is a functional language and that parallel processing is possible?
In that case, when designing DB access processing, should we be careful based on the characteristic of parallel processing?

A summary such as

.
Sorry for not organizing. There are two big questions.

Questions I want to ask-why Elixir + Phoenix is ​​faster

Let's make an Elixir + Phoenix CRUD code or benchmark code ,
(Words are bad) There is only code that is not particularly ingenious (andspawnwhich declares concurrency in Erlang is not used)
I didn't understand why this was possible.

Parallel processing is possible as a language feature, and multi-process in VM is possible
If this is the basis for high speed,Elixir + Phoenix is ​​fast because it uses multi-process processing behind the scenes
Is that okay? Or simply because it is a specification of Erlang's functional language, because BEAM VM is excellent,
Furthermore, because Phoenix is ​​built automatically behind the scenes, is it faster than the script language?
(= The parallel processing function does not contribute to the benchmark result)

Also, if Elixir + Phoenix is ​​doing multi-process processing behind the scenes,
Are all processes that do not use|>converted to parallel processing by Elixir + Phoenix? .
(The following questions are based on this premise. I'm sorry if this is wrong in the first place.)

Question I want to ask-DB deadlock due to parallel processing

I felt suddenly after reading an article about building an API server with Elixir + Phoenix,
Concurrent processing, which is a characteristic of Erlang, seems to easily cause a deadlock when accessing a database.
How is it actually?
(I'm sorry I couldn't come up with an actual example. I'll write what I thought in detail in the next item.)

I can't say well, but in function design,
Is it necessary to design as usual and do not need to consider the characteristics of parallel processing?
Must I design while considering the characteristics of parallel processing? ...

In the latter case, access processing is ultimately performed by the DB
I feel that it is necessary to select a DB that can handle Elixir. Is this actually necessary?
(For example, sqlite is not really multi-process oriented, and PostgreSQL is built with multi-process, so
If i use sqlite as an Elixir + Phoenix database, it will break quickly. . )

Thoughts Assumption 1

Concurrent processing means
Ordinarily create a web application, implement the API in PHP, etc., processing that occurs when multiple people access,
Implemented in Elixir and processing that occurs when one person accesses
I imagine that the same process may run (= simultaneous DB access occurs).

So in the traditional implementation philosophy

  

"Basically, DB access processing defined in function A runs in this order, so
   Even if this design is correct, even if multiple people access it,
  Because everyone should be accessing the database in the same order, there is no problem. ''

was

  

"I defined the process as in function A in Elixir, but it is not clear which process runs first and ends
  Verify all DB access combinations contained in function A so that no deadlocks occur
  You have to think about queries and access "

I feel like

. .

Assumption 2

Although Elixir + Phoenix's early reasons are not well understood,
Looking at the source does not divide the function into very fine granularity or usespawnheavily,
I got the impression that it was getting faster just by writing in the same way as other languages.
It is a selfish guess, but because it is a functional language, is it processed in parallel by function? I have a delusion.
(= A phenomenon likevar rollupin JS occurs in units of functions.
In other words, it is not necessarily processed as written from top to bottom ... )

For example:

// In this case, B and C start at the same time when processing of A starts
public function A () {
  $this->B ();
  $this->C ();
}
// This will process in order
public function X () {
  if ($this->Y ()) {
    $this->Z ();
  }
}
Conclusion

As a typical deadlock example,
There are table A and table B.
Occurs when B has a reference to A, transaction 1 updates to A, and transaction 2 inserts to B
If DB access processing is not processed in order and is processed in parallel, I feel that this is likely to occur easily.

So if the reason why Elixir + Phoenix is ​​fast is as shown in Assumption 2,
If i define the following function, I feel that deadlocks will occur (easy).

def Assuming that spawn is done automatically behind function A_, does this function cause a deadlock? (connect) do
  case TableA.Update (params) do
    {: ok, _}->
      # ...
  case TableB.Insert (params) do
    {: ok, _}->
      # ...

On the assumption that the above code is true,
I feel that deadlock will not occur if I define it in the following form,
I feel that the implementation is very difficult in the callback hell ...
When actually thinking about deadlock, the code for designing the DB access part of Phoenix is ​​
Is it usually in this form?

def Doesn't a deadlock occur if it processes in order using the function A_ pipeline? (connect) do
  case TableA.Update (params) do
    {: ok, _}->
      |>case TableB.Insert (params) do
       {: ok, params}->
         # ...
    {: error, params}->
      |>putMsg (: error, params)
Addendum

I was confused by my own research, so I summarized the concept of the words used here as follows.
(I hope it fits)

The process queued between the
Word meaning
Asynchronous processingfunction and the function is interrupted. An image of turning a kitchen that is delicious with one operation (set the range to 3 minutes, arrange it in the meantime, take it out when i am chinned ...)
Parallel processing (multi-process/multi-task) Start another process. Eat more resources accordingly. Image of processing by multiple people. If not managed properly, it will not synchronize. If i compare it to a store, there is a drive-thru person, a cooker, and a person in charge of cooking. If i don't share your current work properly, your business will be delayed.
Parallel processing (multithreading) Start multiple threads in one process. Memory used by threads is common. Including parallel processing. If i compare it to a store, you can see the movements of chain stores with many stores as an overview.

To be honest, I'm a beginner who knows only the wording of terms likedeadlockandexclusive control,
I have never actually written any code about Elixir,
As you can see from the table above, I don't know anything aboutmulti ***.

Because I was only interested in the reason why this FW is fast and how to handle when DB access occurs in parallel,
I'm sorry if I was completely depressed.

I'm sorry to ask many questions without enough knowledge.
If i know this, thanks for your response.

  • Answer # 1

    I have been interested in it.

    The reason why Elixir + Phoenix is ​​fast

    It's not clear what is fast, but it's compared to something similar.
    The speed is the difference of the framework. Phoenix is ​​fast.
    Check out the architecture to see how fast it is.
    Phoenix Framework (v0.8) Overview

      

    We aim to have the advantages of both high productivity and high application performance.

    I'm aiming, so I'm doing a lot of optimizing instructions to use.

    DB deadlock due to parallel processing

    I think parallel processing here refers to things in the framework, so it will not be.

    Parallel processing performs processing in parallel inside the start and end points, and shortens the length of the section between the start and end points.
    The end point that arrives must be the same as the one executed serially, and the one that performed the processing in parallel must be responsible for it.

    The boundary between the DBMS and the front is a transaction.
    Since the process flow is described in the transaction, there is no room for the parallel element here.
    The DBMS also operates in parallel, but as mentioned above, it is a story between a certain start point and end point in a transaction.

    Exclusion when issuing transactions at the same time is a design-dependent story, and an architecture framework that includes and manages transactions across transactions cannot be general-purpose, so unless you make your own I don't think it exists.