Flow & GenStageに関するJoséValimの最後の基調講演を見てから私は混乱しました。
1）Flow & GenStageがElixirに追加されているのは、並行性を改善することが本当に意味をなさないからです。
2）一方、Erlang/BEAMの重要な強みの1つは、すべてのコアをデフォルトで同時実行/使用していたことであり、開発者はそれを心配する必要はないということでした。
Flow & GenStageが異なるマシン上で実行されている分散システムの助けにならない場合、誰かがFlowとErlang/BEAMの同時実行の違いを説明できますか？なぜElixirは `Flow`を必要としますか？ BEAMではデフォルトで処理されていませんか？
FlowおよびGenStageは、並行性とは異なる問題を解決します。
分散システムで常に起こることは、一度簡単に並行性があれば、システム内の他のすべてのプロセスにとって、単一のプロセスまたは小さなプロセスグループがボトルネックになる「雷鳴」の問題に遭遇することです。このビデオは問題をはっきりと示しています。
FlowとGenStageの重要な概念は、労働者への着信要求のオーバーフローを防止するために、システム内の背圧です。このバックプレッシャーのコンセプトにより、労働者を追加したり、組立ラインを遅くすることができます。
これらのモジュールは、十分に大きなBEAMアプリケーションがすべて実行されるセルフスケジューリングの問題を一般化しようとしています。大量の負荷があってもBEAMアプリケーションが正常に機能しなくなるように、アイデアの実装はすでに多数ありました。
私は同意します。しかし、それは分散システムであり、JoséValimは、あなたが1台のマシンで1つのシステムについて話している場合を示しています。私は背圧の利点も理解しています。欠けているのはErlang/BEAMがErlangの重要な特徴として提示されている場合でも、これを処理する方法です。その作品は私が見逃すものです。 –
BEAMは、1台のマシンまたは100台のマシンで実行される分散システムです。 –
Erlang/BEAMのより一般的なアプローチの直接的で具体的な利点をとる技術の一部として、フローやGenStageを考えてみます。これらのテクニックは、使い方が悪いと結果が悪くなります。これらは、一連のアプリケーションおよびシナリオに合わせて調整されたツールです。 – dimitarvp
Erlangでは、与えられた「プロセス/ PID」に好きなだけ多くのメッセージを送信できますが、あまりに多く送信すると、VMによってキューに入れられ、メモリが詰まることがあります。これらのキューを管理することは、フローのステップである「黒い芸術」です。受信プロセス/ PIDが過負荷にならないようにします。 – GavinBrelstaff