2006/07/18

全文検索結果のハイライトウォーキング

実は私も今日知ったコネタです。多分、私はユーザーとしては Ctrl-F を使うと思うのですが、価値観はそれぞれ・・・ということで、ご紹介します。

How to navigate through full-text search highlights

Notesクライアントで全文検索を行ったとき、文書を開くとキーワードがハイライトされています。実はこの検索結果のハイライトのフォーカスを、キーボードショートカットで進むことができます。

次のキーワード: Ctrl+"+"
前のキーワード: Ctrl+"-"

現在のフォーカスは「ピンク色」になります。

例えば、1つの文書が非常に長く、なおかつキーワードのヒットが文書に少なければ、ひょっとしたら有効かもしれませんが、どうも自分のユーザー的な好みでは、いつもの癖で Ctrl-F しちゃいそうです。

2006/07/17

あるDomino技術者の通勤時間

ここでは決してLifehackの話がしたいのではなく、あくまで1人のDomino技術者が通勤時間で何をしているか、という紹介話です。

私は、もともとハートが小さいタイプなので、他の人が通勤時間をどのように活用しているかには興味があります。特に、自分が尊敬する技術者には、しょっちゅうこの質問をしては、参考にしています。
結局のところ、自分はたいしたことをしていないのですが、何かの参考やきっかけになるかもしれないので書いておきます。

昔は、職場がラッシュと逆方向だったので、Thinkpadを広げて、大量に複製したDBを処理していました。電車の中で仕事をするという概念は、私の当時の師匠の影響もあると思います。その方は、朝は喫茶店で朝食を取りながら仕事をされていましたし、しょっちゅう通勤電車(JR)のグリーン券を買って、仕事をされていました(はかどるそうです)。


そんな刺激を受けているはずの私ですが、今はだいたい次のどれかです
  1. 図書館から借りてきた技術書を読む
  2. 週刊STを読む
  3. 英語のリスニング
技術書はわりと自分で買うほうなのですが、最近、「買っても手をつけない本」が多いのに気づき、むしろ「返却期限が決まっている借りた本」のほうが、きちんと消化出来ることに気づいて図書館の本を読むようになりました。私のように、なかなか自分の意思できちんと読めない人にはよいかもしれません。(最近読んだ本では、これとかこれが面白かったです)


英語はいくらやっても身につきませんが、電車の中で「ヒヤリングマラソン」と「週刊ST」を繰り返しやることで、留学もせずにTOEICで高スコアを出しているDomino技術者が身近におり、その影響でSTを購読しています。難易度も頻度も、自分には最適で、今にも挫折しそうですがそこそこ読んでいます。あと「頭の中だけで英語日記」も時々やりますが、効果のほどはわかりません。

「寝る」というのも、時間の有効活用方法の1つかと思っています。極力ぽーっとした無意味な時間を作らないようにしています。
現代社会で生きていくのはなかなか大変ですね・・・。

2006/07/02

[雑談]通院して思う、トラブルシューティング

非Notes/Dominoネタで恐縮ですが、最近思ったことです。

このG/Wに、ちょっとした炎症をおこしてしまったため、病院に通っていました。すぐによくなった部分もあったのですが、なかなか治らない部分もあって、いくつか薬をかえていました。
前回診察していただいたときに、「うーん、もうXXな原因は治ってると思うので、あとはこの薬を使って下さい。もし治らなければ、次回詳しい検査をしましょう。」と担当医師から言われました。

実はこの薬がものすごくよく効いて、ようやく完治したみたいです。治ればもういい、と言われていたので、特にもう1回通院するつもりはありません。

そこで、ふと思いました。前回の診察は多少自信なさげなコメントだったわけですが、私は「薬が効いて治りました」と、たとえ行かなくても、電話するくらいしたほうがよいのかどうか、ということです。普通の患者は、おそらく、よほどのことがない限りは「治りました」という電話はかけないと思います。でも、医者の立場からすると、どうなんでしょう・・・。ひょっとしたら「治った」という結果を受けることで、担当医師の経験が増え、結果的に社会のためになるかもしれません。


私は、仕事上、突発的にいろいろなご相談を受けることがあるため、「問題事例」はわりと耳にすることもあり、何らか自分が思う解決案や原因となりそうなことをお伝えしています。ところが、「解決しました」という連絡を受ける回数はわりと少ないので、最終的に自分の考えが正しいかの経験が蓄積していかないというジレンマは多少あります。
仕事をやっている上で自分自身が困ることは、プライベートを含め逆の立場では極力行わないようにしたい、ということは日頃思っているのですが、ひょっとして今回の完治問題はその1ケースなのかもしれないと思いました。


そうは言っても、まだ電話してないのですが、家族に医者がいるので、ちょっと医者心理についてきいてみたいところです。

2006/06/30

サーバーエージェントの検証

今日、うちのワカモノからもらった質問:

Q:「不在通知の検証をしたいのですが、今すぐ動かす方法ってないでしょうか?」
A:「うーん、 tell amgr run mail\test.nsf 'OutOfOffice' でどう?」
Q:「おおー、動きました」

Domino 6から、サーバーコンソールからサーバーエージェントを実行することが出来ます。
上記、mail\test.nsfはファイル名で、 OutOfOfficeはエージェント名です。
通常運用で使うのはちょっと変ですが、検証などで待ちきれないときなどは便利でしょうか・・・。

2006/06/28

整合性のチェックとは

こちらもTechnoteの斜め読みから。

What does the message 'Performing consistency check' mean?

「整合性のチェック」はFixupと同義です。サーバークラッシュ後の起動時などによく見かけますが、実はこれには3つの種類があります。
  • unknown state : DBが正常に閉じられなかったとき(クラッシュの後や、開いている最中のOSコピーしたものなど)
  • corrupt state : どこかで破損が起きている場合
  • Questionable integrity : データベースのヘッダやインデックスがおかしいようなとき
整合性チェックが走るのを止めることは出来ません・・・。必要だから行っているという位置づけです。

NotesDBのサイズ

これもよく聞くお話です。

Understanding Notes database size

Notesのデータベースサイズを理解しましょう、というTechnoteより。
Technoteでは、以下の3つの観点でまとめています。
  1. 文書
  2. ビュー(インデックス)
  3. ホワイトスペース
文書というのは、当然ながら、設計要素なども含んだものです。ここらへんは、NotesPeekを使うとよくわかると思います。

データベースの文書数は、DBプロパティから確認可能ですが、サーバーコンソールを使える環境なら、「show database DBファイル名」と入力すると、各設計要素の数や、削除スタブ数も表示されるし、ビューのインデックスのサイズも表示されます。

ビューインデックスについては、上記コンソールからも把握可能ですが、Domino管理クライアントからも実はビュー情報は確認可能です。(「ファイル」タブより、「データベース」→「ビューの管理」)

DBのサイズを最も小さくするためには、compact -d がよいのですが、これは全ビューインデックスが削除されるため、ある意味非常な危険なコマンドです。というのも、次回のユーザーアクセス時にビュー索引を構築する必要があるからです。ビューの構築というのは、非常に負荷の高い操作であり、1つや2つのビューならまだしも、多数のDBに対してビュー構築の動作が同時に行われると(例:サーバー上全てのDBにcompact -dをした場合)、その後のユーザーアクセスピークの間はサーバー負荷は大変なことになります。
ということで、上記Technoteのcompact -dに興味を持った場合も、いきなり週末に本番サーバーで実行・・・というのはお勧め出来ません。

ちなみに、compact -dは、-cスタイルの圧縮になります。

Notesアプリケーション開発時のパフォーマンス考慮

同じくTechnote斜め読みより。

Are there any guidelines regarding performance when developing a Notes application?

細かいお話は、Related Informationというところに入っていますが、基本的には「Performance Considerations for Domino Applications」というRedbookを参照せよとのことです。これはR5における情報ですが、基本アーキテクチャは大きく変更していないので、現在でも利用可能です。

以前のエントリの中でも触れたのですが、上記Redbookは日本語訳もされています。他にもいくつか参考になるのもあるかもしれないので、こちらもどうぞ。

アプリケーションのパフォーマンスが・・・

暗号化されたデータベース

Technoteの斜め読みから見つけたトピックより

Can you find out who encrypted a database?

少し前に、データベースの暗号化 というエントリを書いたのですが、その関連項目です。

暗号化されているデータベースを、「どのID」を使って暗号化したかがわかりますか? というお話。
当然ながら、これはわかりません。

よくある話としては、
  1. サーバー上のDBを直接ファイルコピーした場合はサーバーIDで暗号化されている
  2. ローカルにコピー or 複製したファイルをコピーした場合は、そのコピー、複製オペレーションをしたユーザーIDで暗号化されている
というかんじでしょうか。よく、サーバー移行集約などで、OSコピーなどでファイルを移動してしまった場合、上記「1」のケースがあったりします。旧サーバーのサーバーIDで暗号化されたファイルを新サーバーに移動しても当然暗号化されているため新サーバーはnsfファイルにアクセスすることは出来ません。この場合、旧サーバーID(をノーツクライアントから使って)復号化する必要があります。

2006/06/24

クラッシュとハング

Dominoサーバーのハングとクラッシュに関する英語記事の日本語翻訳が公開されたようです。

Lotus Domino のハングとクラッシュのトラブルシューティング

一言でDominoサーバーの問題といっても、ハングやクラッシュから、パフォーマンスが遅いなど、いろいろとあるのですが、この記事はクラッシュやハングを理解する手がかりになりそうです。

私の個人的な意見では、まず、「クラッシュ」と「ハング」の違いを認識し、情報伝達をするときに、この2つの用語を正しく伝える、というだけで、最初のすれ違いを防止するのに非常に有効だと思います。上の記事では、「ダウン」という言葉も同義で使ってるようです。(私の)日本語的には「サーバーが落ちる」も同義としてよく使います。ハングは「フリーズ」とも言ったりしますね。
よくメールで「サーバーがハングしました・・・」と連絡を受けたりするのですが、多くの場合話を聞いてみると意図したいことは「クラッシュ」だったりするんです・・・。

この記事の中では、いろいろなことが書いてあるのですが、以下のところをきちんと読むのがよいかと思ってます。
  • サーバークラッシュと何か、と、一般的な症状。
  • クラッシュの原因として箇条書きに書かれていること
  • サーバーハングとは何か、と、一般的な症状。
  • サーバークラッシュのトラブルシューティングに書いてある「次の点を考慮します」の箇条書き
これに加え、「クラッシュの調査にはNSDというファイルを調べるのが有効」ということを覚えておけば、わりと遠回りすることなく、問題判別、調査が出来るのではないかと思います。

問題発生時には、いろいろな人が関わる都合上「伝言ゲーム」が多いのですが、少なくとも技術者が関わる部分では誤解のないように伝達しあいたいというのが私個人の希望です。

で、この記事ですが、残りの部分も、読めば面白かったり、役に立つこともあるかもしれませんが、幅広くいろいろと読まされることになるので、まずは上記のとこだけでも最低限読むとよいかと。

2006/06/20

タブの切り替えショートカット

Windowsでアプリケーションを切り替えるときに、「Alt」+「Tab」を使ってる方は非常に多いと思います。私も1日に100回以上使ってると思います。(左手親指+薬指)
それに似た技がNotesの中でも使えますよ、というお話です。

TABbing between Notes windows

Notesクライアントでは、新規ウィンドウをタブ形式で開いていきますが、このタブの切り替えはマウスを使わなくても、「Ctrl」+「Tab」で出来ます。とのこと。

私は10本の指をかなり器用に動かすことが出来るので、「Ctrl+W」のショートカットも左手の小指+薬指で普通に押すことが出来るのですが、ホームポジション・手首固定のタイプ打ちにとって、少なくともThinkpad Tモデルのキーボードでこの「Ctrl」+「Tab」は厳しい・・・。

ということで、マウスを使わなくともウインドウ切り替えられるのは嬉しい反面、自分のタイプ癖からは絶対に使わないショートカットのご紹介でした。 使う人・・・いますかね。

2006/06/15

データベースの文書数

答えがないとわかっていながらも、何かよい答えを言ってくれる人がいるのでは・・・と回答を期待してしまう質問の1つに「Notesのデータベースは何文書まで大丈夫ですか」というのがあります。
でも、きっと本当の意味での正解は、「it depends」でしょう(つまり正解は存在しない)。

そこで、1つの指標として、事例として存在する巨大DBを参考にしてみる、というのが考えられます。残念ながら、私の周りはわりと平和的な使い方をしているため、無謀なケースはあまり知りません。知っている限り最も文書数が多いデータベースは、developerWorks上のフォーラムです。

こちら、2006年6月15日現在のステータスは以下の通り。
Notes/Domino 4 and 5 Forum (Notes1/NotesWeb)
文書数:885,938文書
DBサイズ:9,986MB
全文索引サイズ:1,573MB

実体はこれです。
http://www-10.lotus.com/ldd/46dom.nsf

大量文書を持ちながらも、わりと快適にWebでサービス提供が出来ていることを考えると、データベースの環境次第(DB設計、サーバーの環境)では、100万文書も十分にありえると思います。


さて、「文書数」というのは、ある意味「DBサイズ」よりもパフォーマンスにとっては重要で、特に文書数が多い場合「ビューの数」や「ビューの複雑さ(選択式、列の数、列式、ソートの有無、カテゴリ展開の有無、索引更新の頻度など)」には細心の注意を払わないと、ビューが開かなかったり、サーバー全体のパフォーマンスへ影響があったりします。
また、いかにビューをシンプルにしたとしても、文書数が非常に多い場合、破損時や移行時などのビューの再構築には、それなりの時間がかかるので注意が必要です。


なお、私個人の感覚では、「削除スタブ」の数もパフォーマンスに影響するのではないかと思っています。このため、新規にアプリケーションをデザインするときは、表面的な文書数だけでなく、削除運用を含めた上で、考えたほうがよいと思っています。

既にパフォーマンスに問題のあるDBを調査するときには、文書数のほかに削除スタブの数も知っておきたいところです。削除スタブの数え方はいくつかあるかと思いますが、私はサーバー上で「show database データベース名」を叩いて確認しています。

削除スタブの削除の仕方は、こちらをどうぞ。
How to purge document deletion stubs on the server immediately
もちろん、削除時は複製運用などに注意が必要です。


以上、よく問い合わせを受ける話なので、私個人が持っている意見などを書きましたが、この考えは絶対ではないと思いますし、もっと参考になる事例などもあると思います。あくまで1つの参考としてご参照下さい。またよい事例はシェアさせて頂けると幸いです。

2006/06/10

[雑談] 数独

Notes/Dominoとは全く関係ない話なのですが、IBM Lotus Notes/Domino Hints and TipsSu Doku for Notes - Coming Soon を見て思い出しました。

ニコリ系のパズルといえば、私も若い頃、数独とカックロだけは結構やったのですが、去年 Codestoreを読んでいて、The Soduko Crazeのエントリを見たときに、初めてこの遊びが海外でもブームになっていることを知りました。Wikipediaの英語版にも、Sudokuという形で詳細が記述されています。
確かに昨年末東海岸に行ったときも、空港やB&Nで大量に積んでありました。きっとテトリスが流行したように、シンプルなとこがウケてるのでしょうか。

私自身は最近は空き時間は読書や勉強などに使いたいと思っていますが、一昨年入院していたときは、暇つぶしに結構やっていました。それほど得意ではないんですが、9x9(3x3x9コマ)は時間をかければだいたい解けた気がします。25x25 (5x5x25コマ) は結局1度も解けませんでした。

別にNotes/Dominoの技術者がというわけではないんでしょうが、IT系の技術者はこの手のものはわりと好きなんでしょうね。

2006/06/07

データベースの暗号化

本日、某所から頂戴してきた(つもりの)データベースを開こうとしたら、「指定したデータベースはローカルでのアクセスが制限されているため、アクセスできません。」 というエラーで開くことが出来ませんでした。 折角悲しい思いを経験したので、少しこれについて書いてみます。

Notesのデータベースは、暗号化をすることが可能で、これは、データベースプロパティから操作します。この操作をクライアント上にあるDBに行うと、その時に使っていたユーザーIDファイルで、サーバー上にあるDBに行うとサーバーIDで暗号化が行われます。(もちろん、そのIDのみが復号可能です)

こうして、暗号化されたDBを、ファイル転送など何らかの手段で別のところに移動させても、移動先では暗号化したIDファイルがない限りはDBを開くことは出来ません。
ローカルのDBのセキュリティを考えた場合はデータベースの暗号化は非常に有効なのですが、デフォルトで新規複製を暗号化してしまう設定(にすることが多いと思いますが)にすると、このような落とし穴が時々あったりします。

今回私が経験したように、nsfファイルをWeb上などで公開したり、別の人に渡すときなどは注意が必要ですし、もしくは、データベースを別のサーバーに移動したりする場合は注意が必要です(複製を利用して作成した場合は問題ありません)。

「共通のアクセス制御リストを利用する」オプションでも同様な現象を経験することがありますが、こちらはHackする方法は一応あります。一方、当然のことですが、暗号化には抜け道はありませんので注意が必要です。

2006/06/06

Hannoverのデモ

音声付きの動画として、Hannoverのデモが公開されています。

Hannover demo

メールやカレンダーを中心に新機能が紹介されていますが、私個人は、ここで紹介されていないけれど画面にちらっと見える、Google Desktop Searchという文字列や、AtomのSubscribeとかそういうところも気になりました。

Hannoverの開発状況については、日々Mary Beth Raven のBlogで報告されています。まだまだ固まっていないところや、開発途中のところもあるかと思います。以前、R5でワークスペースがなくなる危機があり、ユーザーの声で勝ち残ったことがありましたが、Hanooverの開発はわりとユーザーからの声の影響が大きいのかな、と思いながらブログを眺めています。

2006/06/03

Lotus Notes on Web 2.0

こっそりと購読していたブログなのですが、codestoreで紹介もされたようですし、ここでも参考程度にご紹介してみます。

Lotus Notes on Web 2.0

私もこの手の話は好きなので、AjaxやRSSについて、時々このブログでもキーワードを並べていますが、「Lotus Notes on Web 2.0」ではもっと実践的に、Ajaxを中心に、prototype.js などスタンダードなライブラリを含む JavaScript の話が展開されているので、Web開発者の方には面白いと思います。私個人もここのアップデートを楽しみにしている人の1人です。

Dominoでなくて、何故Notesなのかというのは名前付けの問題だけと思いますが、このブログがマレーシア発だというのも、個人的には興味深いところです。

2006/06/01

ServerTasks行に関する思い

いつものごとく、RSSリーダーにて、英語版サポートページ(Knowledge Base)を超斜め読みしていたところ、反応してしまった1件。

Maximum character limit in notes.ini is 256 characters per variable

ServerTasks行の文字は255文字までが有効ですよ。というお話。
この話は、NAMES= で旧来よりよく聞いた話で、そのためにファイル名を長くしないように努力する例も聞いたことがあります。いよいよこのネタも ServerTasks行へ突入したのか・・・と思いました。

ところで、この行に255文字も詰め込むということは、それなりの数のタスクがロードされるわけですが、本当にそれだけのタスクが必要なのかな、と思わないわけではありません。

以前、アプリケーション開発を専門としている知人が、

「私のPCはメモリが不足していて、サーバーが完全に起動しないんですよ」

と言ってましたが、実際に設定を見てみると、ServerTasks行に、POP3やらIMAPやら、当時のテストには全く不要そうなものを含む、大量のタスクが書いてありました。必要程度までこの行のエントリを削除したら、無事にサーバーが立ち上がったのを覚えています。


パフォーマンスに問題がある本番サーバーの設定を見る機会も多いのですが、一応必ずここの設定は確認するようにしています。もちろん、実際のサーバー環境ともなると、不要タスクを落とす程度では微々たるものかとは思いますが。
例えば、Statsタスクとかは、通常不要です(STATS サーバータスクは何を行うのですか)。個人的にはmapsタスクもあまり好きではないです。


さて、リソースが制限されるテスト環境では、この設定の見直しはお勧めです。テスト環境では再起動をする回数も多いと思いますが、そういう時、このタスクの数によって、再起動が非常に楽になります

私の現在のテスト端末では、
ServerTasks=Update,Router,AMgr,AdminP
という設定にしています。AMgrとかAdminpは消してもいいのですが、今のところ何故かついていました(消そうかな)。本当はHTTPもよくテストするのですが、結局毎回手動でloadしています。ここらへんは好みによると思います。

あと、深夜にテストするときに、ServerTasksAt1とかで時々悲しいことになるので、ここらへんの行は私のテスト環境ではコメントアウトしています。

2006/05/29

ビューの情報をExcelへ

私自身は日頃使わない、というか、多分1度も使ったことがないのですが、ふと思い出したので書いておきます。

Notesのビューで選択した情報を、クライアントのメニューから「表形式でコピー」することが出来るのは、かなり有名だと思います(Notes 6以降)。
ここでクリップボードにコピーしたビューのテーブル情報は、そのままExcelなどに貼り付けることが出来ます。

これも、予想通りIBM Lotus Notes/Domino Hints and Tipsに既に書いてありました。

Copy data from Notes to a spreadsheet

お手軽ネタなので、小規模構成にどうぞ、とのこと。自動同期ソリューションではないので・・・。


その他、Notes 6からは、ビューにグリッドが入ったり、ビューから直接編集出来るようになったりしているので、もしクライアントが完全にNotes 6以降で統一されているのなら、こういった機能も利用してもよいかなと思います。

2006/05/28

WebページからNotesへのコピー&ペースト

Notesに限った話ではないのですが、自分が普段使っている小技を書いておきます。

Webで情報を検索して、ページの1部(パラグラフであったり、単語であったりしますが)をNotesクライアントに貼り付けることはよくあります。メール本文やディスカッションフォーラムに貼り付けることが多いです。
ところが、Webブラウザからコピーすると、「HTML形式」をそのままコピーするため、Notesのリッチテキストフィールドに普通に貼り付けると、HTML属性(色とかサイズとか、その他いろいろ)が維持されてしまいます。一方、本当は文字列の中身だけを貼り付けたいんだけれど・・・というニーズも多いと思います。

これまで、よく使っていたのは、メニューの「編集」→「形式を選択して貼り付け」→「文字」という方法でした。Notes以外のアプリケーションでも同じことが起きる可能性がありますが、こういったメニューがないアプリケーションでは、仕方なく一度テキストエディタにペーストしてから、再度コピーしていました。

ところが、最近、Firefoxの拡張に、 Copy Plain Text という拡張があることを知りました。形式を選択して貼り付けもよいのですが、やはり、Ctrl-Vで貼り付けたいという希望もあると思います。
そういう場合、この拡張を使うと、クリップボードに「テキスト形式」で簡単に貼り付けることが出来ます。
IEの場合はちょっとわかりませんが、Firefoxユーザーには便利だと思います。

2006/05/23

リストの上下並べ替えショートカット

前回Ctrl-M のご紹介をしたのですが、もう1つ、あまり知られていないけれど、結構便利なショートカットを思い出しました。

リストや表をNotesの機能を使って作っているとき、順番を入れ替えたいときってよく出てくると思います。こんなとき、Notes 6からの新機能を使うと、ショートカットキーだけで簡単に入れ替えることが出来ます。

Ctrl + ↓ です。矢印キーとCtrl。上に行く場合は↑です。

本来は、マインドマップなどを書いてきちんとブレインストーミングするのがよいのでしょうが、ちょっとしたことを箇条書きにする場合、思いついた順に書き並べ、これで順番を並び替えて頭を整理するなんていうのは、私はわりとよくやります。
下のエントリが浮かび上がっていくのは、なんとなくバブルソートを思い出させる操作です。

こういうことは、Alan Lepofskyがわかりやすく書いているのではと思い検索してみると、やはりありました。絵が書いてあるので、直感的に理解しやすいかと思います。

Re-arranging values in a list or cells in a table

2006/05/18

アプリケーションのパフォーマンスが・・・

アプリケーションのパフォーマンスが悪い。

そんなときに、どこを疑いましょうか。
また、そんなことにならないように、何を注意しましょうか。

というトピックで、お話をする機会があったのですが、参考となる主要リソースをここにまとめておきます。いまさら的な話ですが、何かの役に立つかもしれませんので。
個人的には、そんな話をきくと、ビューの状況(数や個々の複雑さ、選択式、列など)と読者フィールドの使用状況、あとWebエージェントの呼ばれ方などが真っ先に気になります。
フォームまわりでは、@DBLookupの呼び方も、影響が大きいみたいです。

その他、ループの書き方、@関数の利用、データベースプロパティなど細かい項目もいろいろありますが、上記3つのリンクが参考になるかと思います。


読者フィールドが与えるパフォーマンスの話は、思ったより知られてない可能性があるようなので、ちょっと引用してみます。

Reader Names フィールドがパフォーマンスに与えるインパクト より引用
ノーツ/ドミノがあるビューを表示したとき、フルページ (64K) のデータを引き出そうとするからです。データベースが Reader Name フィールドを使用するとき、サーバーは、データがフル・ページになるよう十分な文書を検出するまで、それぞれの文書の Reader Name フィールドをチェックしなければなりません。結果的に、ビューで、限られた数の文書にアクセスしているユーザーがこのビューを操作しようとした場合、ペー ジ全体を文書で埋める前に、サーバーは何百何千もの文書を検索します。このプロセスの間、そのビューを他のユーザーが操作しようとすると、初めのユーザー の検索処理が終了するまで、後のユーザーは待たなくてはなりません。実際、Reader Name フィールドが検索されるのを同時に待つユーザーが増えるほど、サーバー・パフォーマンスは損なわれていきます。
文書数が大量にあって、1人が見れる文書が極端に少ない時のお話です。