我們提供了一種簡便的方法並將在本文中介紹。基於多年來評估定製的Notes應用程序來診斷性能問題方面的豐富經驗，我們編譯了影答覆用程序性能的最通用的屬性。我們在一系列文章的第一篇文章中介紹衆所周知的影答覆用程序性能的數據庫、視圖和表格屬性。我們將闡述何時使用某些屬性，何時不使用某些屬性以獲得最佳性能，適當時我們爲您提供備選解決方案。本文假設您是一位富有經驗的Notes應用程序開發人員。
數據庫屬性
當應用程序成爲一種產品時數據庫屬性經常被忽略。但事實是通過啓用和禁用某些屬性，您可以提高性能且不會造成功能、開發時間和管理資源方面的損失。我們將討論以下影響性能的通用數據庫屬性：
不保留未讀標記
不覆蓋空閒空間
保留LastAccessed 屬性
不支持指定的答覆層次
Web訪問：需要SSL連接
所有這些屬性都包含在數據庫屬性對話框中。前四個屬性位於Advanced標籤，最後一個屬性位於Database Basics標籤。
無可否認，這一屬性讓人迷惑，因爲它讀起來就像雙重否定一樣，但缺省情況下，數據庫對所有讀和未讀文檔都進行了標記。這可以用於用戶希望瞭解在討論論壇中哪些主題和答覆是新的和未讀的。但是，跟蹤讀和未讀的文檔會影響應用程序的性能。例如，假設您有一個有1,000,000 份文檔的知識數據庫。有10,000名用戶訪問該數據庫，其中許多用戶使用選擇的複製公式本地複製該數據庫。當用戶複製時，它遇到了最初的延遲，因爲本地和服務器複製器同步它們的未讀標記（Unread Marks）表。這一流程需要與實際數據複製一樣長的時間。這意味着當用戶複製時他們將遇到長延遲。同樣，當訪問服務器上的數據庫的用戶最初打開數據庫時也會遇到延遲，因爲該程序必須讀取未讀標記表，以確定顯示哪些文檔爲讀/未讀文檔。這一延遲可能只持續數秒，但在用戶的腦海中，它算得上是一次反對您的應用程序的罷工了。
要禁用這一功能，選擇數據庫屬性對話框"高級"標籤上的不保留未讀標記選項。在R5 和Notes/Domino 6中，這一功能將影響整個數據庫，而不僅僅是某個視圖。
不覆蓋空閒空間
在Notes Release 3和更早的版本中，Notes 保留了刪除的數據-未加密的數據-直到刪除了empty space或white space爲止。在版本4中對這一功能進地了微妙的改進，從而刪除的數據用隨機字符覆蓋，以便可以對其進行重新檢索。(這稱爲覆蓋空閒空間。)在Release 5 和Notes/Domino 6中，您可以選擇啓用/禁用這一功能。覆蓋空閒空間將對數據庫性能產生負面影響。
爲了幫助您瞭解這一特性，例如，我們考慮從您的桌面PC中刪除一些文件。當您在Windows 操作系統中刪除文件時，它直接放到回收站。然後您可以清空回收站，系統顯示該文件已經永久刪除。現在我們討論當清空回收站後，您意識到實際上很需要這份文件。該文件就這樣永久消失了嗎？ 不是這樣的-它不再存在您的回收站中，但它仍舊在您的計算機中。在適當軟件工具(例如Norton Utilities)的幫助下您可以檢索到這一已刪除的文件。
因此，做爲一種安全性措施，當您刪除Notes文檔時，Notes覆蓋已刪除的數據，以防止任何人重新檢索到它。當您按下F9或選擇視圖- 刷新時，該文檔被刪除。設想您的Notes文檔從：
The quick brown fox jumped over the lazy dog
到：
XX XXXXXXXXXXXXX XXXXXXXXXXX XX X XXXXXXXXXX
注：這一例子不能準確地闡述Notes是如何覆蓋已刪除的數據的。
此時，用戶是否可以檢索到刪除的文檔已經無關緊要的，因爲數據自身已經被破壞了。注意，如果您對文檔進行了軟刪除，Notes不會覆蓋該文檔。只有硬刪除才能激活覆蓋功能。
大多數情況下我們無需保留覆蓋的數據。但是，也有一些您希望Notes 繼續覆蓋刪除的數據的情形：
服務器和數據庫的物理訪問受到損害，從而非法用戶可以使用它們。
數據庫未加密或ACL使數據庫易於遭受攻擊。
企業部署了需要這一功能的安全性策略。
如果您的企業、服務器或數據庫未出現以上任何一種情形，那麼考慮禁用這一功能－選擇不覆蓋空閒空間選項。
維持LastAccessed屬性
我們在Release 4中開始引入了維持LastAccessed屬性；它跟蹤最近訪問文檔的日期(也就是讀或修改文檔的最後時間)。缺省情況下，數據庫只跟蹤最後修改文檔的時間，但通過選擇維持LastAccessed屬性功能，數據庫還可以跟蹤最後讀取文檔的時間。當然，爲了實現最佳的應用程序性能，您希望取消選定這一功能。
但是，這一功能對正在歸檔文檔的用戶很有用。例如，返回我們包含1,000,000 份文檔的知識數據庫例子，設想每天向數據庫增加1,000份新文檔。由於要增加如此多的文檔，我們發現有必要對早期文檔進行歸檔。我們可以使用維持LastAccessed屬性功能，找出最後訪問文檔的時間，以確定哪些文檔要被歸檔。我們可以保留LastAccessed屬性來設置歸檔特性，以歸檔在最近18個月內未打開或讀取的任何文檔。
您可能希望使用這一功能來幫助歸檔文檔到期、過期或短生命週期的任何數據庫中的文檔，例如，討論數據庫或工作流程數據庫。但是，您可能不希望在文檔很少訪問或無最後訪問的日期要跟蹤的數據庫中使用這一功能，例如，在幫助臺應用程序中。
要記住的另外一件事是：LastAccessed屬性不適用於Web應用程序。這一屬性忽略Web瀏覽器的讀取操作。
不支持指定的答覆層次
不支持指定的答覆層次使您的應用程序能夠充分利用指定的答覆@公式：@AllChildren和@AllDescendents。這些功能允許您根據父級文檔和所有答覆文檔的指定標準來構建視圖。現在我們以包含10,000主題和100,000答覆文檔的討論數據庫爲例。假設您創建了一些只顯示某些類別的視圖，如應用程序性能。如果只對100個主題進行了分類，您可能期望該視圖能夠顯示這100個主題以及所有相關的答覆文檔(以及答覆文檔的所有答覆文檔)。Notes傳統上依賴於Selection公式，如：
SELECT (Form = "Main Topic" & Categories = "Application Development") | @IsResponseDoc
遺憾的是，這一公式爲您提供了所有100,000份答覆文檔。您大概不希望看到其中大多數文檔，因爲您的視圖將有一個答覆層次。但它們全部到位，從而減緩了您的視圖索引速度並佔用磁盤空間。如果您選擇了指定的答覆層次(在Release 4中提供， Release 5 和Notes/Domino 6中的可選功能)，那麼您可以使用稍微不同的公式：
SELECT (Form = "Main Topic" & Categories = "Application Development") | @AllDescendants
這一公式爲您提供您正在查找的一組準確的文檔，從而最大限度地減少您的視圖索引和磁盤空間需求。
迄今爲止，我們只告訴了您啓用這一功能的原因(也就是，不選中這一選項)。但是如果您的應用程序未使用那些使用@AllChildren或@AllDescendants的公式，那麼該程序沒有任何理由來維持這類信息，因此您可以通過選擇不支持指定的答覆層次來縮短處理時間。
Web訪問：需要SSL連接
Web訪問：需要SSL連接選項爲每個Web事務提供一個SSL(安全套接層)連接，從而對客戶機和服務器之間傳輸的所有數據都進行了加密。在您實現SSL之後，您和您的用戶將體驗到近10%的性能下降。但是，每個應用程序的架構將影響這一百分比。在實現了SSL後，每個信息包都被加密， 從而需要在客戶機和服務器之間進行多次來回傳送的應用程序需要多次加密。
例如，假設您有使用SSL對所有表格數據進行加密的表格。該表格包含一個@DbLookup 公式。SSL對客戶機和服務器之間的每次事務進行加密，因此，除了對錶格數據進行加密之外， SSL還對查詢事務進行加密。
有些時候爲您的應用程序提供SSL是不可避免的。例如，企業策略可能要求在特殊的應用程序上運行SSL。另外，在某些情形下實現SSL最恰當不過了，例如當客戶機位於 一個國家，而服務器位於另一個國家時。如果您不能確定是否可以相信一個網絡，最好的方法是實現SSL。如果您有一個值得信任的網絡-一個您不認爲會受到損害的網絡-那麼您的應用程序不需要SSL，您和您的用戶的性能也不會受到任何影響。
創建個人文件夾/視圖
創建個人文件夾/視圖是一項ACL功能。獲得此項特權的用戶可以創建專用視圖和文件夾並把它們保存到託管數據庫的服務器上。創建多個視圖，尤其是大視圖，會影響性能，因爲它需要額外的索引。同樣需要注意的是管理員或開發人員很難刪除保存在服務器上的專用視圖和文件夾。
compact 和updall 任務
儘管壓縮應用程序和運行updall任務來刷新視圖索引是不錯的數據庫優化措施，但它們通常不會明顯提高應用程序的性能。但也有例外，如有佔非常大比例White Space的數據庫。但對具有5%或10%White Space的數據庫運行compact 不能實現任何顯而易見的性能增益。
視圖屬性
有許多影響視圖性能的關鍵領域：
時間/日期敏感的公式(選擇或列公式)
時間/日期敏感的公式(選擇或列公式)
閱讀者名稱字段!
ODBC 訪問
時間/日期敏感的視圖
時間/日期敏感的視圖是一種包含具有時間/日期公式（如@Modified 或@Now）的列或具有時間/日期公式的選擇公式的視圖。這些視圖可以提供強大的功能，但它們也是高成本的性能方法。每隔15分鐘， Domino服務器運行更新任務來刷新數據庫中的所有視圖索引。用戶不能對這一項任務進行配置(也就是說您不能配置該任務來按不同的時間表運行)。假設在上午9:00該項任務運行以刷新數據庫中的所有視圖。在上午9:02，修改該數據庫中的文檔。在上午9:15，該更新任務再次運行，注意系統已經修改了這一數據庫中的文檔。它可能已經被郵寄、複製、創建、更新、刪除，但不管怎樣，自從上次更新任務運行後文檔修改發生了，因此必須檢查該數據庫以查找過期的視圖。
此時，系統把有可能包含修改的文檔的所有視圖標記爲過時視圖。並且所有時間/日期敏感的視圖被標記爲將要過時的視圖。因此，除了更新您合理假設需要更新的視圖外，索引指示器還需要更新所有時間/日期敏感的視圖。但事情變得更糟糕了。這些視圖不能被刷新；它們必須重建，重建工作需要非常長的時間。爲了形成這一時間觀念，如果您進行某些敏感的診斷工作，您將發現普通視圖需要100毫秒的時間來刷新，但普通的時間/日期敏感的視圖需要10-50秒(不是毫秒)來刷新，因爲它們是真正的在重建。在一臺繁忙的服務器上，每15分鐘有許多的數據庫需要檢查，有許多視圖需要更新，您的運行環境承擔不起在單個視圖上花費這麼長的時間。
同樣需要注意的是設置視圖屬性對話框刷新字段爲手工刷新(相對於自動刷新或一段時間後自動刷新)可以迅速地打開視圖且不會影響15分鐘的更新任務。
如果視圖刷新未設爲手動，那麼每次用戶打開該視圖時，它強迫進行重建。當然，使用這一設置意味着當用戶打開該視圖時，它沒有必要是最新的，因此您必須權衡性能優勢和過期數據潛在的劣勢。
時間/日期敏感的視圖是一項非常有用(但極其昂貴)的功能，因此請小心使用。
檢查日誌文件
如果您不能確定刷新或重建視圖的時間，請使用日誌文件。在服務器配置文件中選擇Log_update=2，以記錄索引指示器刷新/重建視圖的時間。它列出刷新/重建的每個數據庫中的每個視圖，從而使您能夠跟蹤對某一視圖或數據庫花費了多長時間。經過一些實踐，您就可以相當迅速地找出服務器上發生的任何故障。
時間/日期備選方案
我們提供您可以爲時間/日期敏感的視圖實施的備選方案：
根據 http://www-1.ibm.com/support/docview.wss?uid=swg27003557 上的《Time/Date Views in Notes: What Are the Options? 》中介紹，在選擇公式中使用 @Text。這種備選方案有一定侷限性，但非常有用，它是一個不錯的執行程序。
運行代理來標記將在時間/日期敏感的視圖中顯示的文檔。例如，如果您有一個顯示狀態爲"Open"且DueDate 爲在今天之前的文檔的視圖，您可以夜間運行代理，用OverDueFlag = "是"來標記這類文檔，從而您的視圖選擇公式只需要檢查這類標記。文檔關閉後這類標記也將被刪除。雖然這是單服務器數據庫的重要解決方案，如果您的用戶經常使用本地複製文檔，它並不是最佳的解決方案，因爲它們必須複製每天代理的數據更改。同樣，如果您的數據庫複製到全球的數十臺服務器，您可能不希望使用這一功能。
創建根據日期對文檔進行分類的視圖。這一解決方案很簡單，因而經常被忽視。使用上面的例子，創建一個根據DueDate對所有狀態＝"Open"的文檔進行分類的視圖。用戶可以輕鬆地檢查過期的文檔或將到期的文檔，只需簡單地滾動到正確的日期類別。
列排序
列排序是允許用戶按升序、降序或兩者對視圖中的列進行排序的一項功能。視圖列上的每個排序箭頭增加了視圖索引以及它用於刷新該視圖的時間。從用戶界面和維護角度來看，最好是擁有大量排序箭頭的單一視圖，而不是多個視圖。但是，從性能角度來看， 關鍵是避免向視圖添加過多的排序箭頭且不減少視圖的整體數量。爲了給出一些特殊的標準，您將發現向視圖添加兩個排序箭頭將增加近似兩倍的索引工作/時間，四個排序箭頭增加四倍的視圖索引工作/時間。
提示：檢查只用於查找的隱藏視圖，在這些視圖中並未使用排序箭頭，因此如果存在它們應該被刪除。
讀者姓名字段
讀者姓名字段並不是視圖的屬性，但它們會影響視圖的性能。讀者姓名字段可以爲文檔提供安全性，但會對顯示包含讀者姓名字段的文檔的視圖產生負面影響。例如，假設您爲10,000 名員工建立了一個人力資源數據庫並假設有一個顯示所有10,000 份文檔的平面視圖（未分類視圖）。由於閱讀者姓名限制，每位員工只能看到自己的文檔。當員工打開數據庫時，Domino服務器對文檔進行排序來確定將向該位用戶顯示的文檔。通常，如果沒有讀者域，系統將向用戶全屏顯示前30份文檔。您可以打開視圖，按向下箭頭來進行一次快速測試，以確定這一點。您可以迅速滾動瀏覽十幾行；然後稍微停頓一下，通常時間低於一秒，同時服務器讀取另外一塊將被顯示的數據。滾動瀏覽以30行重新開始，然後發生另一次停頓。
但是，在HR應用程序中，服務器不能在用戶顯示界面上全屏顯示數據。這不是問題，但服務器無法知道它不能全屏顯示，因此它繼續對所有10,000份文檔進行排序，旨在查找用戶可以看到的更多的文檔。最後，遍覽所有文檔之後，服務器放棄，並顯示一份文檔，但延遲時間可能會很長。在獨立的運行環境中，延遲時間可能爲數秒，但在真實的生產環境中，有許多用戶正在嘗試執行相同的任務，由於延遲， 大多數用戶會出現超時。
有數種備選方案可以幫助您避免這一問題：
對視圖進行分類，選擇"首次打開數據庫時摺疊所有的文檔"選項取消視圖中的類別。雖然這一設置會稍微影響性能，這是真的，但是在這種情況下它將帶來大量的優勢。
不要選擇"不顯示空分類"選項以只顯示包含文檔的類別。選擇這一功能將產生與使用平面視圖相同的結果：在向用戶顯示任何事件之前服務器必須檢查所有10,000份文檔。
使用顯示一個類別的嵌入式視圖。使用@UserName公式來顯示屬於該位用戶的文檔。這是一個奇妙的執行程序，它也將傑出地爲Web瀏覽器工作。
注：視圖中與讀者姓名字段相關的性能問題是一樣的，與用戶是使用Web瀏覽器還是Notes客戶機無關。
ODBC訪問
ODBC訪問屬性"在索引中產生唯一的關鍵字"爲數據庫的相互關聯提供唯一的關鍵字。您可以使用這一屬性來進行快速查找。方法是：假設您有包含10,000 個主題和100,000份答覆文檔的討論數據庫。該數據庫包括只顯示10,000 個主題的隱藏視圖，旨在查找所有現有的類別。如果您選擇了隱藏視圖的ODBC訪問屬性，您可以將每個類別的文檔數量減少到一份。這一屬性取消了所有複製的文檔。使用隱藏視圖上的@DbLookup將實現快速查找，因爲它顯著縮小了視圖的大小。例如，如果在數據庫中只有50個獨一無二的類別，這種隱藏式查找視圖將只包括50份文檔而不是10,000份。
注：如果您的文檔有多個類別，您需要在視圖列公式中使用程序代碼 ，以確保可以顯示和查找到所有類別。
表單屬性
只有一種表單屬性真正影響應用程序的性能：自動刷新字段。如果您在表單中激活了自動刷新功能，每次您從一個字段移動到另一個字段時，自動刷新功能更新所有先前的字段。例如，當您移動到表單中的第二個字段時，自動刷新功能更新表單中的第一個字段，當您移動到第三個字段時，它更新第一個和第二個字段。這一功能最新將影響應用程序的性能，尤其是表單使用工作流程和查找時。對於包含驗證公式的簡單表單來說，自動刷新功能幾乎不會影響性能。對於較複雜的表單來說，考慮使用退出事件而不是自動刷新。
結語
在本文中，我們討論了一些將影響應用程序性能的最普通的屬性；但是，定製的應用程序會有一些將影響性能的獨特的屬性組合。雖然您有可能體驗到改進的性能啓用或禁用本文中介紹的功能，您仍將發現測試您的應用程序以查看是否可以實現進一步改進很有用-記住，應用程序性能測試是一項艱驗、耗時的工作。在本系列文章的下一篇文章中，我們討論將影響應用程序性能的代理和程序代碼。