前回のシリアル/パラレル処理の視点に立ってコネクションプールについて考えてみたい.
コネクションプールが遅いとは
はてなおやさんが考察しているように
普通にmod_perl でコネクションプールを素直に張るとコネクション数が爆発する.
図にすると図1のような感じで個々のapacheがコネクションを複数持つので,サーバ台数が増えるとコネクション数が飛躍的に増えることがわかると思う.
図1 コネクションが爆発してる様子(正直書くのも大変)
コネクション数が増えると単純にコネクションを維持するコストも増えていくので，
このあたりが「コネクションプーリング都市伝説」の根拠になっていると思われる.
これはこれで全くその通りで間違いない.
さて,ここでもうちょっと大きな視点に立って,クライアント<->サーバ間の通信路が
1個の伝送路をパケットによって多重化しているととらえてみたい.そうするとここで
シリアル/パラレルの発想が適用できることに着目して欲しい.
つまり
図2 パケットによりリクエストが多重化されているのをシリアル化する.
図2の上の図が下の図のようにできればリクエストが逐次処理になるのでコネクションを複数張る必要がなくなる.
つまりうまくやると下記のようにできるということだ.
図3 リクエストをシリアライズすることでコネクションを減らせている様子.
実際はセッション管理などケアするなど考慮することはたくさんあるが,
コネクションが減らせていることがわかると思う.
このような考え方についてはLeader/followersデザインパターンとして2000年に発表されている.
Douglas C. Schmidt, Carlos O'Ryan, Michael Kircher, and Irfan Pyarali, Leader/Followers - A Design Pattern for Efficient Multi-threaded I/O Demulitplexing and Dispatching , PLoP 2000 conference, Allerton Park, Illinois, USA, August 13-16, 2000
http://www.kircher-schwanninger.de/michael/publications/lf.pdf
ベースにある考え方は今までのエントリの通りなので,
興味ある方はあわせて読んでみるといいと思う.
さて,ここまで説明したところでみなさんには一つ謝らなくてはならないことがある.
ここまで読んでくれたみなさんの興味は
「OK.言いたいことはわかったよ.で,そういう実装はあるの?」
というところだろう.SQLRelayやpgpoolをサーバ側ではなくクライアント側に
配置することでそういう効果を生み出せると思ったが,思ったような効果は
出ないようだ(なにかすごいソリューションがあることを期待しちゃった人は
申し訳ない).
ただ可能性としてLeader/Followersデザインパターンを適用すれば
スケールアップに強いコネクションプールができると言うことは理解してもらえたと思う.
グダグダになってしまった感があるが,結論としては下記のようになる.
1. MySQLのコネクションプールは確かに遅いかも知れない
2. でもそれは実装の話でスケールアップに強いコネクションプール(の実装方法)もあるよ
3. だからコネクションプール→すなわち遅いにはつながらないよ
4. 決めつけ(・Д・)イクナイ!.ベンチマーク常に重要
(おしまい)
yamaz的日常
このエントリ群は早めに出すつもりだったけど,うまくまとまらなくて
1ヶ月以上放置してしまった.ここにきて気になってしょうがない度が
Maxに達してしまったので,まるまる1日仕事を休んで一気に書き上げてみた.
Blogを定期的に書いてる人を見るにつけ,みんなすごいなぁとほんとに感心する.
