2009年1月10日土曜日

レスポンスを気にせずとりあえず実装すること

何かアプリケーションを作成する時に、レスポンスはとりあえず置いといて実装...ってケースってよくあると思うんですが、先日たまたまそぅいぅ話をしている所に居合わせて思った事。

いざレスポンスを向上させよう!というタイミングが来てチューニングして行く時、みなさん思い通りな結果になるように修正って出来てるもんなんでしょうか?
昔はSQLをチューニングする事が大きな部分を占めるチューニングだったような気がしますが、今ってSQLプラスαの部分ってどんなものがあるのかなぁ。
コードの内容を修正することによるレスポンスUpってのは、全体からみると微々たる向上でしか出来ない事が多いと思うし。

クライアント側でAjaxが一般的に使われるようになって、体感が早くなったと思うのですが、使用するユーザもそれに慣れて要望は厳しくなってるんですよね。多分。
昔の3秒ルールっつーのはもぅ無かったりするんでしょうねぇー。

そこで思い出して来たのが、「並列実行」。
以前、分散実行を行なえるようなツール作った事があったんですよ。
依存関係、プライオリティなどを指定したタスク(処理)を登録し、複数の端末(マシン)に処理を振り分けて実行させるようなもの。ま、それだけの簡単なものでしたが。
そこで感じたのが、”作成するアプリにて、どれだけ並列実行できるような仕組みにしておくか”というのが一番重要で大変。
でも、並列実行が出来るようなアプリの作りにしておくと効果は凄いです。当然ながら。
並列実行できるのであれば、特に分散実行でなくても複数のThreadつかって一気に処理ってのも出来ますしね。

んじゃー、最初から並列実行しやすいような作りで! といわれても...難しい気が。
個人的にはGoogleのMapReduceのような並列の仕組がリスクもすくない形でいいなぁと思うのですが、気軽に作成を進めていけるようなフレームワークや言語があればいいなぁ。。
コーディング中は頭で理解しやすい形..SingleThread(笑)..で出来て、実行時には切替ができるとか?
まぁ、MapReduceであればフレームワークなんて大げさなものでなくて、ライブラリ的なもので十分そうですけども、いざという時には分散実行に切替ができるようなフレームワークがあるとなんかカッチョ良いなぁなんて。
JPPFとかはちょっと大げさすぎる気がするので、GridGainの簡易版ぐらいのもの...

現時点でもぅ、マシンのハード的にもクロック数は頭打ちになり、変わりにコア数が増えてくる状態になっていると思うので、並列実行はぴったりマッチするだろうし、見過ごしできないモノなんだろうなぁーと思います。
• • •