2

JPA私のベースレイヤーのストレステスト中DAO（それぞれ別のスレッドで同時に500回の同時更新を実行しています）。私は次のことに遭遇しました - システムは常に進行できずに動かなくなりました。

問題は、ある時点でどのスレッドにも利用可能な接続がなかったため、実行中のスレッドが進行できなかったことです。

私はこれをしばらく調査しましたが、ルートは私REQUIRES_NEWの.addJPA DAO's

したがって、シナリオは次のとおりです。

  1. テストはトランザクションを開始するために新しい取得を開始しConnectionます。ConnectionPool
  2. いくつかの初期段階の後、私はadd自分の を呼び出して、存在しないDAO別の を要求Connectionします。これまでに、 は並行して実行されているテストによって取得されていたためです。ConnectionPoolConnections

DataSource 構成で遊んでみました

  1. c3p0立ち往生
  2. DBCP立ち往生
  3. BoneCP立ち往生
  4. MySQLDataSourceエラーでいくつかの要求が失敗しました - 許可された接続数を超えました。

すべてのデータソースが完全に機能するREQUIRES_NEWを読み取ることで解決しましたが、スタックせずに失敗するだけなので、それでも最良の結果はMySQLDataSourceのようです:)

したがって、高いスループットが期待される場合は、REQUIRES_NEW をまったく使用しないように思われます。

そして私の質問：

この REQUIRES_NEW 問題を防ぐことができる DataSources の構成はありますか?

c3p0 でチェックアウト タイムアウトを試したところ、予想どおり、テストが失敗し始めました。

  • 2 秒 - 8 % 合格
  • 4 秒 - 12 % 合格
  • 6 秒 - 16 % 合格
  • 8 秒 - 26 % 合格
  • 10 秒 - 34 % 合格
  • 12 秒 - 36 % 合格
  • 14/16/18 秒 - 40 % 合格

もちろん、これは非常に主観的なものです。

単純な構成の MySQLDataSource は、合格したテストの 20% を提供しました。

4

2 に答える 2

2

接続を取得するためのタイムアウトの構成についてはどうですか? たとえば 2 秒以内に接続を取得できない場合、プールは中止され、例外がスローされます。

REQUIRESまた、より典型的であることに注意してください。チェーン内の新しい呼び出しごとに新しいトランザクションを開始するのではなく、呼び出しチェーンでトランザクションを共有することがよくあります。

于 2012-12-09T20:21:48.117 に答える
2

おそらく、どの接続プールも、さまざまな方法でこれに対処するように構成できます。最終的に、すべての REQUIRES_NEW によって、アプリはクライアントごとに複数の接続を取得することを余儀なくされ、ストレス テストのストレスが増大します。プールがハングしている場合は、接続が不足している可能性があります。十分に大きなプール サイズを設定すると、問題が解決する場合があります。または、Arjan が上記で提案したように、クライアントが接続を待機する必要がある場合は、無期限にハングするのではなく、プールを「高速で失敗する」ように構成できます。c3p0 では、その構成パラメーターは checkoutTimeout になります。

接続プールが「動かなくなった」と言うときに正確に何が起こっているかについての詳細情報がなければ、これは必然的に当て推量です。ただし、同時負荷が非常に高い場合、どの接続プールでも、大量のリソースを使用可能にする (maxPoolSize + c3p0 の numHelperThreads を高くする) か、過剰なクライアントを追い出す (checkoutTimeout) か、クライアントを長時間 (ただし有限! ) 待ち時間。

于 2012-12-10T11:00:47.293 に答える