クライアントとサーバー間のDB通信においてネットワークがボトルネックとなる原因の多くはネットワーク帯域の不足だと思います。
この場合、パフォーマンスモニタやDBの各種イベント情報などからインフラ側でも検知しやすいです。
ボトルネックが検知しにくい過剰なラウンドトリップ
ボトルネックが検知しにくいものはクライアント起因でネットワークラウンドトリップが多くなっている場合です。
例えば大量のSELECT結果をクライアントに送信する場合、DBサーバー側では結果セットをメモリ上に保持しますが、クライアント側では全てを一度に処理することは出来ないため一度にすべてを返却せず複数回に分けて返却する動きになります。
１００万行のSELECT結果があり、仮に１万行ずつクライアントに返却する場合、クライアントとサーバー間で１００回のラウンドトリップが発生します。
この回数が多いと当然ネットワーク遅延が大きくなり、介在するネットワーク機器が多いとさらに遅延が大きくなっていきます。
このような場合、DBサーバー側のH/Wリソースは十分に見え、異常があるようには見えないため、DBサーバー側だけの調査ではボトルネックを検知することは難しい場合が多いです。
ラウンドトリップが原因の場合の対応
データ転送量自体の削減、またはフェッチサイズやキャッシュサイズの見直しが主な対応方法となりますが、まずはフェッチサイズ、キャッシュサイズが想定通りとなっているかを確認しましょう。
これらはドライバーによって規定動作が変わるためクライアント側で明示的に指定していない場合は規定動作を確認しましょう。
フェッチサイズ、キャッシュサイズなどを増やすと基本的にパフォーマンスは良くなりますが、サイズを増やした分メモリ消費量も増加するため、クライアント側でメモリ不足エラーが発生する可能性があります。
クライアントのリソースが十分確保されていることを確認した上でサイズを増やしましょう。
以上
