[PHP-users 13991] Re: 社内システム構築のためのDB環境について

[Naoki Shibata]

柴田です。

遅い画面に出くわしたことがあります。そのときは
メインのSQLでFetchした一件一件のデータを使ってSQLを作成しさらに実行、つ
まり1000件あれば1001回SQLを発行していました。そんなことさえしなければど
んなDBMSを使っても1000件程度で、大きくレスポンスが落ちるということはない
と思います。

数万から数十万程度のDBから100件程度を表示するシステムを運営しています
が、DBのアクセス自体は無視できるほど早いものです。いかにインデックス読み
をするか、インデックスのないjoinを作らないかなどテーブル設計のつぼをつか
めば問題ないはずです。SQLをローカルで発行してみれば一目瞭然でチューニン
グが出来るはずです。結構キー作成忘れでjoinして遅くなっているケースが多い
です。
無視を出来ないのはhtmlの組み立てのためのプロセスです。収めるときにコード
変換をすれば良い物を表示のときにしていたり、同様に複雑な計算や分岐をして
いたり、CPUを食っているケースがたくさんあります。収めるときは1回、表示す
るときはn回ですから、2度以上そのレコードを読むなら書き込むときに表示用の
フィールドを足してでもプロセスを書き込み時に持っていくべきです。全体の
20%以上が読まれるなら、書込み時にプロセスを持っていくべきだと考えています。
究極は書き込むときにhtmlを作成してしまうプレパブリッシュです。ポータルサ
イトで一覧メニューをプレパブリッシュに変えて、1/100程度になった経験があ
ります。書込みは遅くなりましたが、それでも3回アクセスしたらトータルで
チャラになりました。

とは言っても1000件程度では、どんな作りをしてもと思いますが・・・

> どこがボトルネックになって遅いのか測定してみましたか？
> CPU の早いマシンと遅いマシンで表示速度に圧倒的差がありませんか？
> その表示ページを wget などで取得すると、速度は圧倒的に違いませんか(早い)？

私は、まず切り分けをするために
・バッチ版のphpで動かす
・リモートからwgetで取得する
・最後にブラウザー経由で
という順で追っています。
最初でつまずけば、まずスクリプトかDBデザインの問題
次であればたぶん回線かWebサーバーの問題
最後まで行けばhtmlの問題
という感じです。問題がある場合、経験上ほぼ全部が最初でつまずきます

> # おそらく <table> で表示してるんじゃないかと。
テーブルは確かに、ブラウザーが最後まで読んで描画を決める（回避する方法も
ありますが）ので遅くなる可能性もあるけれど、そんなに遅くなった経験はあり
ません。