SlickがnumThreadsについてよく混乱していて、良いパフォーマンスを得るためのベストプラクティス

Question

SlickでPlayFrameWorkを使用していて、すべてのI/Oデータベースが重いシステムで使用しています。私は、この設定を持っている私のapplication.confファイルで：

play { 
    akka { 
    akka.loggers = ["akka.event.slf4j.Slf4jLogger"] 
    loglevel = WARNING 
    actor { 
     default-dispatcher = { 
     fork-join-executor { 
      parallelism-factor = 20.0 
     } 
     } 
    } 
    } 
} 

これは明らかに私のプレイアプリケーションのコアあたり20個のスレッドを与え、私はそれはスリック、それは自身のスレッドプールだ作成NumThreadsフィールドは、それが合計だとスリックの平均であることを理解としてスレッド数または（NumThreads x CPU）？最高のパフォーマンスを得るためのベストプラクティスはありますか？スレッドプール内のスレッドの簡単な数がある

database { 
    dataSourceClass = "org.postgresql.ds.PGSimpleDataSource" 
    properties = { 
    databaseName = "dbname" 
    user = "postgres" 
    password = "password" 
    } 
    numThreads = 10 
} 

Answer 1

NumThreadsに：として私は現在、私の設定が設定されています。 Slickは、このスレッドプールを使用してクエリを実行します。

The following config keys are supported for all connection pools, both built-in and third-party:

• NumThreadsに（INT、オプション、デフォルト：20）： データベースアクションの非同期実行のスレッドプール内の同時スレッドの数。 スレッドプールのサイズを正しく調整する方法については、HikariCP wikiを参照してください。 Slickで非同期の を実行する場合は、最大接続プールサイズではなく、スレッドプールサイズ（ パラメータ）を調整する必要があります。

• QUEUESIZE（INT、オプション、デフォルト：1000）：すべて のスレッドがビジー状態のとき、すぐに実行することができないデータベース・アクションのためのキューのサイズ。この制限を超えると、新しいアクションは即座に失敗します。 キューがない場合（直接ハンドオフの場合）は0に設定され、キューサイズが無制限の場合は-1に設定されます（推奨されません）。

デフォルトでプールは非同期実行用に調整されています。接続パラメータとは別に、ほとんどの場合numThreadsとqueueSizeを設定するだけで済みます。このシナリオでは、接続を介してではなく（キューを介して）スレッドプールに対する競合が発生するため、接続の最大数にはかなり大きな制限があります（データベースサーバーが処理できるものに基づいています効率的）。トランザクション内の非データベースアクションをシーケンシングするときに、Slickはプール内のスレッドより多くの接続を使用します。

次のconfigキーがHikariCPのためにサポートされています。

• URL（文字列、必須）：JDBC URL

• ドライバやdriverClassName（文字列、オプション）：JDBCユーザーをロードするドライバクラス（文字列、オプション）*：ユーザー名

• パスワード（文字列、オプション）：パスワード

• アイソレーション（文字列、オプション）：新しい接続のトランザクション分離レベル。指定できる値は、NONE、READ_COMMITTED、 READ_UNCOMMITTED、REPEATABLE_READ、SERIALIZABLEです。

• カタログ（文字列、オプション）：新しい接続のデフォルトカタログ。

• readOnly（ブール値、オプション）：新しい接続の読み取り専用フラグ。

• プロパティ（マップ、オプション）：ドライバまたはデータソースに渡すプロパティ。

• dataSourceClass（文字列、オプション）：JDBCドライバが提供するDataSourceクラスの名前。これは、 ドライバを使用するよりも優先されます。このキーが設定されていると、URLは無視されます（ では、プロパティを使用してデータベース接続を設定する必要があります）。

• MaxConnectionsを（INT、オプション、デフォルト：NumThreadsに* 5）：プール内の接続の最大数。

• minConnections（INT、オプション、デフォルト：NumThreadsに同じ）：プールに保持する接続の最小数。

• connectionTimeout（継続時間、オプション、デフォルト：1秒）：getConnectionの呼び出しがタイムアウトするまでの最大待機時間。この 時間を超えて接続が使用可能にならない場合は、 SQLExceptionがスローされます。 1000msが最小値です。

• validationTimeout（継続時間、オプション、デフォルト：1秒）：接続の有効性をテストする最大時間。 1000ms が最小値です。

• idleTimeout（継続時間、オプション、デフォルト：10分）：接続がプール内でアイドル状態になる最大時間。 値が0の場合、アイドル状態の接続はプール内の決して削除されません。maxLifetime（期間、オプション、デフォルト：30分）：プール内の接続の最大寿命は、 です。アイドル接続が このタイムアウトに達した場合、最近使用されても、 プールからリタイアされます。 0の値は、最大有効期間がないことを示します。

• connectionInitSql（文字列、オプション）： プールに追加する前に、すべての新しい接続を作成した後に実行されるSQL文。このSQLが有効でないか例外がスローされた場合は、 が接続障害として扱われ、標準の再試行ロジックは になります。 initializationFailFast（ブール値、オプション、デフォルト値：false）： プールに の初期接続を正常に設定できない場合に、プールが「失敗する」かどうかを制御します。プールの起動時に接続が にできない場合、RuntimeExceptionがスローされます。 minConnectionsは0

• leakDetectionThreshold（時間、オプション、デフォルト：0）である場合、このプロパティは効果がありません：接続は、メッセージの前にプールからとすることができる時間の量は を示す記録され接続漏れの可能性があります。 0の値は、リーク の検出が無効であることを意味します。リークを有効にするための最低許容値は で、10秒です。 connectionTestQuery（String、optional）： という文は、データベースへの接続がまだ有効であることを確認するために、 プールから接続が取得される直前に実行されます。 これはデータベースに依存しており、データベースによって処理される処理量が非常に少ない（たとえば、「VALUES 1」）クエリでなければなりません。設定されていない場合は、代わりにJDBC4 Connection.isValid（）メソッドが使用されます（通常は が望ましい）。

• registerMbeans（ブール値、オプション、デフォルト：false）：JMX管理Bean（「MBean」）が登録されているかどうか。

スリックは非常に透過的な設定をしています。優れたパフォーマンスのためのベストプラクティス、サムルールはありません。データベース（並列接続の数）とアプリケーションによって異なります。データベース&アプリケーション間のチューニングがすべてです。