本ブログの更新について

　本ブログの更新は2016年3月31日をもって終了しました．ありがとうございました．
posted by みっちぃ （管理人）
<< 今さえ良ければいいのか | TOP | リニアの車窓 >>

2013年07月13日

遅い原因

ん〜、某システムが遅い主因は10ぐらいあるテーブルへInsertやUpdateをする際に、テーブルごとにDB ConnecionをOpen/Closeしていることにある気がしてきた。しかもこの処理は、その前のSelectで取得したレコード数の分だけ繰り返し実行される（ようだ）。 なんでこんな実装にしちゃったのさ…（涙
posted by みっちぃ （管理人） at 01:17| Comment(4) | TrackBack(0) | 日記
この記事へのコメント
コネクションプーリング使っていないのですか？ちょっといまどきそれは考えられない実装ですね。
Posted by しま at 2013年07月13日 11:11
しまさん．コメントありがとうございます．

接続文字列に指定は無かったのですがOracle Connector デフォルトではコネクションプーリングするようになっていたと思います．プーリングされていればこのことによる性能低下は無視ほどになるんですかね？

いずれ時間計測のコードを埋め込んで原因特定したいとは思ってますが・・・．
Posted by みっちぃ（管理人） at 2013年07月13日 11:45
コネクション取得は比較的重い処理なので、プーリングし再利用することで速度向上は見込めます。

# というか、そう思ったので「テーブルごとにDB ConnecionをOpen/Closeしていることにある気がしてきた。」と言ったのですよね。

また、通常DBのConnectorでプーリングを実装していることはないと思います。コネクションプーリングはJavaのWebシステムであればAPサーバで大抵実装されています。アプリケーションは自前でコネクションを取得するのではなく、APサーバから取得することで、裏ではプールされたコネクションを利用することになります。
Posted by しま at 2013年07月13日 13:30
># というか、そう思ったので「テーブルごとにDB ConnecionをOpen/Closeしていることにある気がしてきた。」と言ったのですよね。

いえ，ちょっと違いますね．Connection Pooling自体は現状作用しているはずなので，Open/Close自体が足を引っ張っている可能性はそれほどでも無いかもしれません．

むしろ，テーブルごとにOpen/Closeすることによって，その都度Commitも発生していることになります．addBatchしていって後からまとめてCommitする実装に比べるとかなりの差になっていると思われます．まぁ，この点は時間を計れば明らかになるでしょう．

これを治そうにもテーブルごとにOpen/Closeしている現状では修正範囲が広く，それが根本的な原因とも言えることから“主因”と表現しました．

まぁ，この実装には何か理由があったのかもしれません．今度聞いてみましょうか．
Posted by みっちぃ（管理人） at 2013年07月13日 15:16
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/70852675
この記事へのトラックバック