そんなときに、どこを疑いましょうか。
また、そんなことにならないように、何を注意しましょうか。
というトピックで、お話をする機会があったのですが、参考となる主要リソースをここにまとめておきます。いまさら的な話ですが、何かの役に立つかもしれませんので。
個人的には、そんな話をきくと、ビューの状況（数や個々の複雑さ、選択式、列など）と読者フィールドの使用状況、あとWebエージェントの呼ばれ方などが真っ先に気になります。
フォームまわりでは、@DBLookupの呼び方も、影響が大きいみたいです。
その他、ループの書き方、＠関数の利用、データベースプロパティなど細かい項目もいろいろありますが、上記3つのリンクが参考になるかと思います。
読者フィールドが与えるパフォーマンスの話は、思ったより知られてない可能性があるようなので、ちょっと引用してみます。
Reader Names フィールドがパフォーマンスに与えるインパクト より引用
ノーツ/ドミノがあるビューを表示したとき、フルページ （64K） のデータを引き出そうとするからです。データベースが Reader Name フィールドを使用するとき、サーバーは、データがフル・ページになるよう十分な文書を検出するまで、それぞれの文書の Reader Name フィールドをチェックしなければなりません。結果的に、ビューで、限られた数の文書にアクセスしているユーザーがこのビューを操作しようとした場合、ペー ジ全体を文書で埋める前に、サーバーは何百何千もの文書を検索します。このプロセスの間、そのビューを他のユーザーが操作しようとすると、初めのユーザー の検索処理が終了するまで、後のユーザーは待たなくてはなりません。実際、Reader Name フィールドが検索されるのを同時に待つユーザーが増えるほど、サーバー・パフォーマンスは損なわれていきます。文書数が大量にあって、1人が見れる文書が極端に少ない時のお話です。
0 件のコメント:
コメントを投稿