本文翻譯自IBM Lotus網站LDD Today 2003/04/01所發表的文章

作者：Tara Hall 原文網址連結

譯者：Louis Lee & Kate Huang

Notes應用程式的效能調校

應用程式的效能是一個用來測量應 用程式在特定環境與工作負載下如何運作的方式。您可以測量應用程式的效能嗎？當然可 以，若要測量應用程式的效能只需要一個獨立的測試環境，其中包括與您實際線上環境類 似的網路環境、載入測試軟體以模擬使用者與使用者的作業，以及很多時間。應用程式的 效能測試與 伺服器的效能測試不同，所以您可以在應用程式的效能測試中排除CPU、RAM、NICs等影響變數，如此一來，應用程式效能測試的意義就是指在同一時間內嚴密測試one field on one form in one view。若要測試某些複雜的客制化 應用程式，就是冗長又不斷一直重複的步驟了。沒有人會知道當您精簡設計元件、公式、script，或屬性以後所花的時間，是否會阻礙您的應用程式在最佳化的情況下執行。

但是當我們在解 釋此一文章時，其實還有一個簡單的方法。基於多年來對客制化的Notes應用程式之相關 效能評估經驗，我們已經收集了大部分會影響應用程式效能的屬性。在這此系列中的第一 篇文章，我們會談到我們已經知道會影響應用程式效能的資料庫、視界，以及套表屬性。 我們會 提供您多種不同的改善方法，也就是告訴您何時該使用或不該使用某些特定且合適的屬性以達到最佳效能。在此篇文章中，我們假設您是一位有經驗的Notes應用程式開發者。

資料庫屬性

資料庫屬性 在應用程式上線時往往都會被忽略。但是事實上，您也許可以 在開發時期或是管理資源時，啟動或是取消這些特定屬性，這樣就可以不用犧牲您所開發的功能而達成改善效能的目的。接下來就讓我們來看看下列會影響效能的一般資料庫屬性：

• 不保留未閱讀文件的記號
• 不要覆寫可用空間
• 保留LastAccessed屬性
• 不支援特定的回應階層
• Web存取：需要SSL連接

不保留未閱讀文件的記號

不可否認地，這是一個會讓人困惑的屬性，因 為讀起來像是雙重否定，以預設值而言，資料庫中所有已閱讀與未閱讀的文件都會被追蹤 。這對於使用者在討論區中要辨識哪些主題與回應文件是已閱讀或未閱讀是很有用的。然 而，追蹤已閱讀與未閱讀的文件會對應用程式的效能產生影響。舉例來說，假設您有一個 知識資料庫，其中具有一百萬份文件。此資料庫的會被一萬位使用者所存取，而且大部分 的使用者都會使用抄寫選擇公式來將資料庫中的文件抄寫到本區中。當某位使用者在執行 抄寫時，本區抄本與伺服器抄本在同步它們的未閱讀標示表時，他就會感覺到啟動延遲。 當此程序在抄寫資料時將會花上一段時間，也就是說當您的使用者在進行抄寫時會覺得抄 寫時間太久了。同樣地，當使用者在開啟位於伺服器上的該資料庫時也會察覺開啟時間過 久，因 為程式必須經由未閱讀標示表來決定要對使用者標示哪些文件是已閱讀或是未閱讀。延遲情況也許只是幾秒鐘，但是在使用者的心裡，這可能就會讓使用者對您的應用程式扣分了。

所以若要取消此作業，請在資料庫屬性方塊的進階標籤下勾選 不保留未閱讀文件的記號 選項。在R5與ND6中，此選項會對整個資料庫產生影響，而不是只對特定視界中的文件產生影響。

不要覆寫可用空間

在Notes R3與之前的版本中，Notes會保留已刪除的資料(未加密資料)直到資料庫被壓縮後置放那些已刪除資料的white space被清空為止。在R4時代，此功能已經微妙地變成，Domino會以隨機字元(random char acte rs)覆寫已刪除資料以使其無法恢復(這被稱為覆寫可用空間)。在R5與ND6中，您可以選擇啟動或取消此功能。因為覆寫可用空間這功能對資料庫的效能會有負面的影響。

為了幫助您了解此一功能，舉個例子來說，讓我們來看看那些被您從筆記型電腦上刪除的檔案。當您從Windows OS中刪除檔案時，它會被直接丟到資源回收筒中，然後您可以清空資源回收筒，如此一來 該檔案就會真正的消失了。但是，當您在清空資源回收筒之後，卻 發現您又需要那個檔案了。這檔案真的永遠消失了嗎？並不一定喔－它也許不再存放於資源回收筒，但是它仍然存在於電腦中。這時候您就可以使用適當的軟體(例如Norton Utilities)來救回您的檔案了。

基於安全考量，當您刪除一筆Notes文件時，Notes會覆寫該筆資料以預防其他人再去取回該份文件。當您按下F9或選擇 檢視->重新顯示 後，此文件就會被移除掉，想像一下您的Notes文件會從：

這時候，不論任何人要是可以再次 存取 此份文件的話，都是很不正常的狀況，因為此資料已經被破壞了。請注意，如果您對一份文件執行軟刪除的話，Notes並不會覆寫該文件。只有在硬刪除時才會啟動覆寫動作。

在大部分的狀況中，並不需要啟動覆寫資料的功能。然而，有一些比較特殊的狀況，您就需要啟動Notes的覆寫資料功能了：

• 不允許未經認證的使用者經由實體存取伺服器與資料庫的方式來存取它們時。
• 資料庫並未加密，或ACL讓資料庫處於開放的狀態時。
• 企業組織具有需要此一功能的安全政策時。

保留LastAccessed屬性

保留LastAccessed屬性在R 4中就已經採用；它會追蹤文件最後一次被存取的日期時間(文件最後一次被閱讀或是修改的日期時間)。以預設值而言，資料庫只會追蹤文件最後一次修改的日期時間，但若勾選 保留LastAccessed屬性 選項的話，資料庫也能追蹤最後一次被閱讀的日期時間。很自然的，若要讓資料庫擁有好的效能，就要取消此一選項。

然而此選項對於 使用者備存文件是有用的。例如，再回到 我們之前提到的知識資料庫，其中包含一百萬筆文件，想像一下每天都會新增一千筆新文件。由於有許多新文件一直新增進來，所以我們發現有必要去備存舊的文件。我們可以使用 保留LastAccessed屬性選項來記錄文件最後一次的存取日期時間是何 時，並且依據此日期時間來決定哪些文件需要備存。例如，我們可以設定備存功能的備存條件為凡是超過LastAccessed屬性日期時間十八個月以上之文件都予以備存。

您有可能會使用 此選項來幫助任何資料庫備存期滿文件、過時文件，或是生命 週期短的文件，例如，討論園地資料庫或是簽核流程資料庫。然而，在經常被存取或是沒有最後存取時間日期可以追蹤的資料庫中，您就不需要使用此一選項了，例如說明資料庫。

另外要注意的一件事情是：LastAccessed屬性並不支援Web應用程式。此屬性會忽略Web上的閱讀動作。

不支援特定的回應階層

不支援特定的回應階層 可以讓您的應用程式使用特有的回應公式：@AllChildren 與 @AllDescendents。此公式 可以讓您根據父文件與其所有的回應文 件之特定條件來建立視界。讓我們來看個討論資料庫的例子，假設此討論資料庫中擁有一萬筆主題文件以及十萬筆回應文件，而且您建立了少數幾個只顯示特定分類的視界，例如以 應用程式效能為主題來分類。如果您以這一百筆主題文件的主題來分類 的話，可以預料到的是此視界除了會顯示這一百筆主題以外，還會顯示這些主題文件的回應文件(以及回應文件的回應文件…等等)。習慣上來講，是依靠視界選擇公式的，像是：

SELECT (Form = "Main Topic" & Categories = "Application Development") | @IsResponseDoc

不幸的是，此一視界選擇公式會顯示出一萬筆 回應文件。您一定不想要看到這大部分的文件，因為您的視界已經有回應階層了。但是他們還是全部都出現在那兒了，而且降低視界索引的速度，並且也佔用硬碟空間。假如您使用 特定的回應階層 (在R4是啟動的，在R5與ND6是選擇性的)，您就可以使用一個稍微不同的公式了：

SELECT (Form = "Main Topic" & Categories = "Application Development") | @AllDescendants

此公式可以精確無誤的給您所想要的文件，這樣一來您的視界索引與硬碟空間的需求就會降到最小了。

到目前為止，我們只告訴您為什麼您應該啟動這一功能(也就是不勾選此選項)。但是，假如您的應用程式中並沒有使用 @AllChildren 或 @AllDescendants 公式，這時候就沒有理由來為此程式保留這個資訊了，所以您可以藉由選擇 不支援特定的回應階層以取消特定的回應階層來節省處理循環了。

Web存取：需要SSL連接

Web存取：需要SSL連接選 項可以對每一個Web的資料交易來啟動SSL，這樣一來，所有在用戶端與伺服器之間傳送的 資料都會予以加密。在您啟動SSL之後，您與您的使用者就會察覺到效能大約會降低百分 之十。然而 ，各應用程式的自身結構也會影響到此百分比。當SSL被啟動後，每一個資訊封包都會被加密，所以一支需要在用戶端與伺服器來回傳遞許多資訊的應用程式也需要許多的加密。

這裡有一個例子：假設您有一個套表已啟動SSL來加密所有的套表資料。此套表中包含一個 @DbLookup 公式。SSL會加密每一筆在用戶端與伺服器間傳遞的資料，所以除了加密套表資料以外，SSL也會加密查詢的交易資料。

有時候，為您的 應用程式啟動SSL是不可避免的。例如，由於企業的政策，所以必須在特定的應用程式上 啟動SSL。另外，在某些特定的狀況下SSL就是一種擔保，例如，有個用戶端是在某個國家 ，而伺服器又在另一個國家，這時候啟動SSL就可以保護他們傳輸的資料。假如您沒 有把握是否可以信任網路，就可以啟動SSL來加強安全性。然而，假如您有一個可以信任的網路，這時候您的應用程式就不需要SSL了，因為可以避免您與使用者的效能降低。

建立私有的視界/資料夾

建立私有的視界/資料夾是一個ACL選項。若是使 用者在資料庫中具有此一權限，就可以在伺服器上的資料庫中建立私有的 視界與資料夾。建立許多視界，尤其是大型的視界，會因為額外的索引需求而導致效能降低。而且需要注意的是，管理員與開發人員很難刪除儲存在伺服器上的私有視界與資料夾。

Compact與Updall作業

壓縮(Compact )您的應用程式與執行Updall 作業以更新視界索引是對資料庫的好習慣，雖然它們通常無法改善應用程式的效能。不過也有例外的情形，像是資料庫的White Space佔有很高的比例時。不過若是資料庫只有百分之五到十的White Space，即使壓縮也不會提高多少的效能。

視界屬性

影響視界效能的主要因素如下:

• 時間/日期 sentitive公式(視界選擇或是直欄公式)
• 直欄快速排序
• 讀者姓名欄位
• ODBC存取

所謂 時間/日期sentitive視界，是指視 界直欄中具有時間/日期相關公式的視界，例如@Modified、@Now，或是以時間/日期公式作為選擇公式的視界。這些視界的功能強大，但效能也相對的要付出代價。 Domino 伺服器每隔15分鐘會執行更新程序去重整資料庫內的視界檢索。這是無法手動設定的程序，(也就是說， 您不能變更執行的排程)。假設這個程序在每日上午09:00會更新資料庫裡所有的視界，在0 9:02時，資料庫裡的某份文件被編輯過，在09:15更新程序再度執行時，就會注意到資料 庫裡這 份被編輯過的文件。這份文件有可能是郵寄進來，抄寫，新建，更新，或是被刪除等等，但無論如何，只要文件在更新程序執行過後又被修改，資料庫裡過期的視界就又需要更新。

這時，所有視界 都有可能包含編輯過的文件，且被標記為過期，那些有包含時間/日期sensitive公式的視 界也同樣被標示為過期。所以，除了那些您認為理所當然需要更新的視界之外，檢索器也 需要更新全部的時間/日期sensitive視界。這樣的情形會每況愈下。這些視界無法被更新 ；它們必須 花費更長的時間來重建。如果您做一些精確的測試以了解要花多少時間，就會發現一般的視界更新大概要萬分之一秒，可是日期/時間sensitive視界由於要重建的關係， 所以可能 要花上10-50秒。在一部用有許多資料庫的忙碌伺服器上，系統每隔15分鐘就要檢查資料庫並且更新視界，光是在一個視界上就要花費這樣的時間，您的環境可能無法負荷。

另外要注意的是，在視界屬性裡面設定人工更新選項(這是相對於自動 更新或是自動每隔 這兩個選項)，能讓使用者可以很快地開啟視界而且不會影響到每15分鐘的更新程序。

如果視界沒有設為人工 更新，每次只要有使用者打開這個視界，它就會被強迫重建。當然，使用這個設定，代表當使用者打開視界時並不需要最新的資料。 所以您必須衡量在效能和過期資料之間取捨的利弊缺失。

時間/日期sensitive視界非常好用，但是非常耗費效能，所以使用時請小心。

檢查紀錄檔

如果您不確定重新顯示或重建視界要花費多少時間的話，請使用紀錄檔。在伺服器架構文件設定Log_update=2，以便紀錄下檢索器更新或重建視界的時間。 它會將每個資料庫裡更新過或重建過的每個視界都列出來，讓您可以追蹤某個特定的視界或資料庫所花費的時間。 藉由這個練習，會使您變得能很快的發掘伺服器的問題。

時間/日期的處理方法

以下提供一些維護時間/日期sensitive視界的處理方法：

• 在選擇的公式中使用@Text。 請參閱 Time/Date Views in Notes: What Are the Options? (http://www-1.ibm.com/support/docview.wss?uid=swg27003557) 。此方法當然有其限制，但仍然很有用，且是很好的執行方法。
• 執行代理程式來標記應歸類在 過期se nsitive視界的文件。例如，您有一個只顯示Status欄位=”Open”文件的視界，把今日以前的日期設為到期日，您可以在晚上執行代理程式來將這些文件標示為 OverDueFlag = “Yes”。 然後您的視界選擇公式只要檢查這個Flag就好了。當文件關閉的時候，Flag就會被清除掉。雖然對於單一的伺服器來說，這是一個很好的解決方法， 但是對使用本區抄 本資料庫的使用者而言，這並不是好的方法，因為他們必須每日抄寫這代理程式所改變的資料。同樣地，如果您的資料庫需抄寫到全球各地的數個伺服器，您不會想用這種方法的。
• 建立一個以日 期作為分類的視界。這是一個非常簡單以至於常常被忽略的方法。以上述的例子來說，做 一 個只顯示Status欄位=”Open”文件的視界，然後以到期日作為分類。這樣一來，使用者只要到捲動到他要的日期類別裡，就可很容易的查閱過期或是即將過期的文件。

直欄排序選項讓使用者可以將直欄以升冪，降羃，或是兩種皆可的方式排序。 每個在直 欄上的排序箭頭都代表著視界檢索的增加，以及更新視界所要花費的時 間。從使用者介面與維護的角度來看，一個有很多直欄排序選項的視界是比多個視界來得好。然而，從效能的角度來看，則要盡量避免一方面在視界裡建立很多直欄排序選項之後， 另一方面卻沒有去減少視界的總數。以某些特定標準來衡量，您會發現若在視界裡增加兩個排序箭頭，視界的檢索大約會增加三倍， 四個箭頭大約就會增加五倍，依此類推。

秘訣： 檢查只用來作為搜尋用途的隱藏視界，這些僅供搜尋的視界並不需要直欄排序選項， 所以如果有的話應該要拿掉。

讀者欄位

讀者欄位並非視界屬性，但是卻會影響視界的效能。讀者欄位可以提供文件的安全性，但也會對顯示這些含有讀者欄位文件的視界效能產生負面的影響。例如， 您有一個提供給一萬名員工使用的人事資料庫，裡面有一個包含了一萬份文件且沒有分類 的視界，由於每位員工受到讀者欄位限制的關係，只能看到自己的文件。每當員工打開資 料庫，Domino就會開始挑選可以顯示的文件。一般來說，在沒有讀者欄位的情況下，會以 最前面的30份文件填滿使用者畫面。您可以藉由在開啟任意一個資料庫其中一個視界，然 後按著捲軸的向下箭頭快速捲動以快速的 測試確認；伺服器在抓取另一個要顯示的資料之時，會有稍微的停頓，但應該小於一秒。每次捲動捲軸就又會重新抓取最前面的30份文件，然後又會有另一次的停頓，以此類推。

然而，在上述的 人事資料庫例子中，伺服器並沒有辦法將畫面填滿。但其實這並不是問題。但伺服器並無 法得知這個畫面是填不滿的 ，所以它會在一萬份文件中不停的搜尋符合顯示條件的文件，顯示使用者可以看到的文件。最後，在幾經搜尋之後終究放棄，然後只顯示那份文件，但是時間上的延遲卻值得考慮。 在獨立的環境中可能會延遲幾秒，但在實際的環境中，會有許多的使用者執行這個動作，所以應該很容易就會有使用者因為這個延遲而time out。

這裡有一些避免這種問題的方法:

• 將視界分類，並在一開始就先設定 第一次開啟資料庫時收合全部 的視界屬性，以收合視界的分類。雖然這個設定會稍微影響效能，但是整體而言仍可省下相當多的時間。
• 在您只想顯示有文件的類別之時，應避免使用不要顯示空的類別 選項。因為選擇這個選項就像使用沒有分類的視界一樣：伺服器在顯示文件給任何一位使用者之前，都必須一一檢查這一萬份文件。
• 使用嵌入的視界來顯示單一類別的文件。使用@UserName公式來篩選要顯示給該使用者的文件。這是一個非常好的執行方法， 而且也可以在Web上使用!

ODBC(開放資料聯結)存取

ODBC存取的屬性 "在檢索中產生唯一的鍵值" 提供資料庫溝通所用的唯一鍵值。如果您想要能快速的存取，就可以用這個設定。方法如下: 假設您有一個討論園地資料庫，裡面有一萬份主文件和一萬份回應文件。這個資料庫裡面 有一個只列出那一萬份主文件的隱藏視界，以供查詢目前已有的文件類別。如果您使用這 個選項，就可以把這個視界裡面每個類別的文件數降到只剩一份。這個屬性會排除掉所有 類別重複的文件。由於視界的大小已經戲劇性的減少，所以在這個隱藏視 界使用@Dblookup時，就能夠快速的產生查詢結果。比如說，在上述討論園地資料庫裡面只有50個不重複的類別，在這個隱藏視界裡就只會有50份文件而不是一萬份。

要注意的是，如果您的文件選了多重類別，您必須要在視界的直欄公式裡面， 使用額外的程式來確保所有的類別都會顯示出來，而且可以查詢得到。

套表屬性

套表屬性裡面真正會影響應用程式效能的只有一個：自動更新欄位 。一旦您在套表裡啟動自動更新 ，每次您從一個欄位移到下一個欄位時，套表裡面先前的欄位都會被更新。

例如，當您進入 到第二個欄位時，第一個欄位就會自動更新，當您移到第三個欄位，第一個和第二個欄位 就會自動更新，以此類推。這個特性最終還是會降低應用程 式的效能，尤其是當您的套表有用到流程和查詢的時候。如果是包含驗證公式的簡單套表，自動重新顯示對於效能的衝擊非常小。至於複雜的套表，您可以考慮使用exiting events來代替自動更新欄位。

結論

在本文中，我們檢視了一些會影響資料庫效能的常見屬 性；然而，客製的資料庫可能會因為各種因素的結合而影響了應用程式效能。在 您體驗本文所述以啟動或取消屬性來增進效能的同時，對於測試您的應用程式是否還能有所改善來說，也是很有用的－要記得，測試應用程式效能有可能會是困難而且花費時間的。 在本系列的下一篇文章裡，我們要來看會影響應用程式效能的代理程式和程式碼。

譯者Louis註：

這次真的很高興Kate這位高手願意跟Louis一起合作進行翻譯的工作，希望我們的合作能夠拋磚引玉，讓台灣的Notes界的熱心朋友們踴躍提供相關的技術文章。