私は、+ A Nスイッチを介して非同期スレッドプールサイズを増やすことが意味をなすことを理解しようとしているドキュメントを読んでいます。非同期スレッドのサイズをゼロから増やすのが適切なのはいつですか？
私はベンチマークに完全に準備されていますが、プールサイズを0からN（またはNからN + M）に増やすと役立つと思われるときの経験則があるかどうかは疑問でした。 （あなたはもちろん、SMPを使用している場合）
おかげデフォルトで
BEAMはErlangコードをスケジューラと呼ばれる特別なスレッドで実行します。デフォルトでは、プロセッサのすべてのコアのスケジューラが起動します。たとえば、すべてのコアでErlangを実行するのではなく、他のものに対して「予約」したい場合など、これを制御して起動することができます。通常、ファイルI/O操作を実行するとスケジューラーで実行され、ファイルI/O操作が比較的遅いため、スケジューラーが実行中にブロックされます。リアルタイム性に影響を与える可能性があります。通常、それほど多くのファイルI/Oを実行しないので、問題はありません。
非同期スレッドプールは、I/O操作に使用されるOSスレッドです。通常はプールは空ですが、起動時に+Aを使用すると、BEAMはこのプール用にスレッドを追加します（）。これらのスレッドは、ファイルI/O操作にのみ使用されます。スケジューラスレッドはファイルI/Oの待機をブロックしなくなり、リアルタイムプロパティが向上します。もちろん、OSスレッドとしてのこのコストは無料ではありません。スレッドは混在しないので、スケジューラスレッドはスケジューラスレッドだけで、非同期スレッドは単なる非同期スレッドです。
リンク先のドライバをポート用に作成する場合は、非同期スレッドプールも使用できます。しかし、あなたが自分自身を開始したときを検出する必要があります。
あなたのアプリケーションには、必要な数が非常に多くあります。デフォルトでは、起動されません。 @demeshchukのように、Riakは多くのファイルを開くと大きな非同期スレッドプールを持つことが好きだと聞いています。私の唯一のアドバイスは、それを試して測定することです。すべての最適化と同様に？
は、実行中のErlangのVM内のスレッドの数は、プロセッサ論理コアの数と同じです。
私の経験から、+ Aパラメータを増やすと、同時に多数のファイルI/O操作を行っているときにパフォーマンスが向上する場合があります。 BEAMのスケジューラは非常に高速で最適化されているため、+ Aを増やすとプロセス全体のパフォーマンスが向上する可能性はありません。
正確な数字について言えば、それはあなたのアプリケーションに完全に依存していると思います。最大ファイル数が予測可能なRiakの場合、+ Aをこの最大値に設定するか、大きすぎる場合は（デフォルトでは64、BTW）設定することができます。あなたのアプリケーションに何百万ものファイルが含まれていて、それらをWebクライアントに提供すれば、それは別の話です。おそらく、独自のコードと独自の環境でいくつかのベンチマークを実行したいかもしれません。
最後に、私は+ A以上を見たことがないと信じています。それを設定できないわけではありませんが、その中には何の意味もありません。