レイテンシーがかなり高く (~80ms)、帯域幅が比較的広い接続を介して、MySQL (InnoDB) データベースに接続しています。
クエリの発行方法によって、クエリ時間が大幅に異なることに気付きました。次の例では、主キーによって単一の小さな行に対してクエリを実行しています。クエリ時間は次のとおりです。
- コマンド ライン クライアント (
mysql): ~160ms - 生の JDBC: ~240ms
- ハイバネート: ~400ms (~0ms 開始、~160ms 取得、~240ms コミット)
- ハイバネート、L2: ~240ms (~0ms 開始、~0ms 取得、~240ms コミット)
- ハイバネート、c3p0: ~880ms (~160ms 開始、~240ms 取得、~480ms コミット)
- ハイバネート、L2+c3p0: ~640ms (~160ms 開始、~0ms 取得、~480ms コミット)
(「L2」は Hibernate の第 2 レベルのキャッシュが有効になったことを意味し、「c3p0」は c3p0 が有効になったことを意味し、「begin」、「get」、および「commit」は、クエリ中に呼び出されるさまざまなサブメソッドのタイミングです)
これらは、おおよそ「定常状態」の結果であるため、L2 キャッシュはホットであり、Hibernate の起動時間は無視されます。L2 キャッシュが有効な場合、実際には get が発行されないため、「get」は通常 0ms であると想定しています。
私の質問は次のとおりです。
- すべてのクエリが、ネットワーク レイテンシの何倍にもなっているのはなぜですか? コマンド ライン クライアントでさえ、
mysql単純なクエリに 2 回の往復が必要なようです。 - すべての JDBC/Hibernate クエリがコマンドライン クライアントよりもずっと遅いのはなぜですか? 生の JDBC クライアントでさえ、3 回の往復が必要なようです。
- c3p0 がすべてを悪化させるように見えるのはなぜですか? 私が知る限り、接続テストを無効にしましたが、そうでなければ物事を説明することができました.