もう一歩踏み込んでみないかしら？
http://itpro.nikkeibp.co.jp/article/COLUMN/20051111/224435/
会員用のサイトなので、引用控えめモードよ。よろしくってかしら？
WebシステムとDBサーバの拡張に関するお話よ。
http://itpro.nikkeibp.co.jp/article/COLUMN/20051111/224435/ より
Webシステムのボトルネック回避(1)
DBサーバーの負荷分散が有効
そうねぇ。ネタとしてはとても面白いと思うんですの。
http://itpro.nikkeibp.co.jp/article/COLUMN/20051111/224435/ より
「WebサーバーやAPサーバーの性能が低くてDBサーバーの足を引っ張る状態は避けなければならない」（日立ソフトウェアエンジニアリングの紀平篤志インターネットビジネス部長）。高額な投資をかけたDBサーバーの能力を使い切る前にWebシステム全体の性能が頭打ちになってしまっては，せっかくの投資が無駄になってしまうからだ。
っていう発想は面白いと思うんですの。
それで対策方法について書かれているんですけれども、
http://itpro.nikkeibp.co.jp/article/COLUMN/20051111/224435/ より
(3)DBアクセスを経て動的に作られるページをキャッシュする手段も有効。
ってのはまぁメモリやその他とのご相談という関門はあるにせよ、よい着眼点だと思うの。
http://itpro.nikkeibp.co.jp/article/COLUMN/20051111/224435/ より
(2)APサーバーやWebサーバーのパラメータを調整することで性能が向上する場合もある。
ってのも大変によろしくってだわね。
ただ
http://itpro.nikkeibp.co.jp/article/COLUMN/20051111/224435/ より
(1)ハードウエアの拡張
は*1ちょっと微妙だわね。
多くの技術者が念頭からとっぱずしてしまうものの一つに「金額」ってものがあるの。でも、現実問題としてはとても重要だわ。
はっきり言って、Webサーバ*2を増設するのはさほど高い金額がかかるわけじゃないの。ええもちろん「ちゃんとサーバ分散を意識したつくりになっている」事は大前提よ？*3
一方で、DBサーバをクラスタリングなんかすると、一気にとんでもない金額に跳ね上がっていくわ。
ここからいえることは簡単なの。
可能な限りWebサーバ側の処理に負荷をかけて、DBサーバへの負荷を減らす。
これが、特にヘビーな環境で用いられるCGIを設計する際における鉄則よ。はっきり言ってしまえば、あたしは「よっぽど」のことがない限り、JOINも副次問い合わせも、トランザクションですら使わないわ。
…って書くと、きっとDB屋さんが大騒ぎするのよね。一度、そのSQLがサーバにかける負荷ってものを計ってみるといいわ。もちろん「計った上でより優位だからJOINにしました」っていうのはありよ？ でも、恐らくほとんどの人は「取り合えず使って」程度にしか考えてないんじゃなくってかしら？
どんなところでもTPOってのは大切な考え方なの。あたくしたちSEってのは、その場その場に合わせたTPOで発想をしなければならない生き物なのよ？
だから、本当に素敵なのは「沢山の手段」っていう引き出しを持っている人。翻って、あるシチュエーションで考えもせずに「これは＊＊が正しい」なんて頭の固い考え方をするようなSEには存在意義すらなくってよ。
異性や同性*4を口説くにしても、やっぱりTPOってのは欠かせない要素なの。
山盛りのバラの花束を贈るのも、急にバイクで夜明けの海を見に行くのも、とっても女心*5をくすぐると思うの。でも、バイクで移動した先で山盛りのバラの花束をもらってそのまままたバイクで戻るって考えたら…「それってありえなくない？」とかいわれちゃうわよ？
マニュアルに頼らない千変万化の手練手管、あなたはちゃんと身に着けていてかしら？
