コネクションプールとドライバー

色々とアドバイス頂いたので記録
2
V @voluntas

コネクションプールはコネクションを手に入れる前に queue をして、無かった場合は queue に入れてみるというのが必要なのかな。実際作って見るとすげー勉強になるな。やっぱ理論だけじゃだめだ orz

2011-01-03 00:31:29
V @voluntas

そもそもコネクションを取れない場合の処理って普通はどうするんだろう、リトライ?あきらめる?そもそもその状況を作らない?

2011-01-03 00:39:05
takabow @takabow

@voluntas コネクションを取れないというのは、プールに貯めるための新規コネクションを(DB)サーバーに張るときのことですか?それともクライアントがプールにコネクションを取りに来たときのことですか?

2011-01-03 00:50:55
V @voluntas

@takabow 達人来た!クライアントがプールにコネクションを取りに言ったとき、プールが空の場合はどうするのが一般的なのかなと。秒間 5000 リクエストとかを処理したい場合、事前にどの程度コネクション貼っておくのが現実的なんでしょうか。

2011-01-03 00:51:53
takabow @takabow

@voluntas 多くのコネクションプールって設定でmin/max コネクション数を設定できるので、プールが空の場合は設定に依存しますね。maxコネクションに達していない場合は、DBに新規コネクションを張りに行ってプールに蓄えます。maxに達しているときはエラーを返します。

2011-01-03 00:55:26
takabow @takabow

@voluntas ただ 急激なコネクションの増加はソケット生成の負荷などからDB/APサーバー共に急激なCPU負荷が高まるので、多くの場合 min/maxは同一の数値にすることが多いと思います。つまり見込まれる最大数のコネクションをプールに貯めておきます。

2011-01-03 00:56:52
V @voluntas

@takabow なるほど、事前にはっておくわけではなく、max コネクション数を決めておいて足らなくなったら貼る、というのがデファクトなんですね。max になっているときは冷静に error なのは把握しました、とりあえずその実装をしてみることにします。

2011-01-03 00:57:09
takabow @takabow

@voluntas 可能なら見込まれる最大数を事前に張っときますね。

2011-01-03 00:57:59
V @voluntas

@takabow あ、やはり。一応事前にある程度想定でコネクションははっておいてそれを超えたらエラーという仕様にしておこうと思います。並列処理数が増えれば増えるほどコネクションを貼っていく状況になるのかなと。

2011-01-03 00:58:08
V @voluntas

@takabow 話がずれるのですが、コンシステントハッシュを使って事前にレプリケーションサーバを用意しておいて、分散できるような実装がスマートだったりしますか? そうすれば一台一台に張るコネクションは減るかなと。

2011-01-03 00:58:58
V @voluntas

うーむ、明らかに基本的な知識が足りてない気がしてきた。

2011-01-03 00:59:11
V @voluntas

コネクションプールを使った話は多いんだけど、実装した話が意外に少ないんだよなぁ。皆さん困ってないのかな。TCP で並列処理になると確実にプールがいる気がするんだけど ... 。

2011-01-03 01:01:02
V @voluntas

結局コネクションプールよりも毎回コネクションを繋ぐ方が早ければそっちのほうがいいわけか。どっちなんだろう。毎回コネクション繋ぐ実装もしてみてベンチマーク取ってみるか。

2011-01-03 01:03:56
V @voluntas

毎回コネクション開くのは重いってイメージが勝手にあるけど実際はかった事はないしなぁ。

2011-01-03 01:04:29
takabow @takabow

@voluntas それは、コネクションプールを分散するお話ですか?

2011-01-03 01:04:29
V @voluntas

@takabow えーとそうですね。コネクションプール自体を分散することで1台の db サーバに対して張るコネクション数を軽減しつつ、大量のコネクションを確保するというイメージです。

2011-01-03 01:05:08
takabow @takabow

@voluntas コネクションプールって通常APサーバー側にあると思うので、コネクションプールを分散させても、1台のDBサーバーへの接続数はかわらなくないですか?

2011-01-03 01:07:11
V @voluntas

@takabow おふ、AP サーバではなくて Erlang で時前で TCP レベルから書いているので、全て時前で持ってる感じです。なので、DB サーバが複数台あればコネクション数は多いけど、サーバへのコネクションは減るかなと思いました。

2011-01-03 01:08:55
takabow @takabow

@voluntas 毎回コネクション開くと、接続する側される側双方でソケット生成しますが、これらはカーネル側の処理が大きく、コンテキストスイッチやらsysの負荷やらで、接続が集中したとき、簡単にCPU張り付きます。

2011-01-03 01:09:00
V @voluntas

@takabow む、やはり都市伝説ではなく、コネクションプールは必須と考えていいんですね。さらに DB 側の負荷も増える、ということですね。確かにそうだ。お互いに優しいコネクションプールということで理解しました。

2011-01-03 01:09:58
V @voluntas

@takabow コネクション 100 の場合、DB が一つだと 100 だけですが、レプリケーションサーバが3台あれば コネクション 200 でにしても50, 50, 50, 50 という4台の DB それぞれに張られるコネクションは減るかなと。

2011-01-03 01:11:06
V @voluntas

@takabow そうです。DB は別サーバにあって TCP 接続します。コネクション自体は Erlang で管理しています。

2011-01-03 01:11:32
Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp @Guutara

@takabow @voluntas そうなんだけど、それは、それで、起動時の負荷が、高くて、大変なんです〜。

2011-01-03 01:12:34
V @voluntas

@Guutara 1 コネクションに対して 1 軽量プロセスで面倒見るので特にクライアント側は負荷は感じてませんねー。問題になるのは DB サーバ側かなと。そこは特に気にしてません。

2011-01-03 01:13:35
takabow @takabow

@voluntas DBのレプリケーションサーバーが存在する構成の場合、それに対応したコネクションプールを開発するとう認識であっていますでしょうか?

2011-01-03 01:14:44