Maximizing application performance

© Copyright 2001 Lotus Development Corporation. All rights reserved. Printed in the United
States.

Lotus and Lotus Notes are registered trademarks, and Domino is a trademark of Lotus
Development Corporation. Other product and brand names may be trademarks of their
respective companies.

Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Tuning Applications for Maximum Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
How to design applications for maximum performance . . . . . . . . . . . . . . . . . . . . . 3
Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
How to lay out pages for maximum performance . . . . . . . . . . . . . . . . . . . . . . . . . . 7
How to design forms for maximum performance . . . . . . . . . . . . . . . . . . . . . . . . . . 8
How to design views for maximum performance . . . . . . . . . . . . . . . . . . . . . . . . . 12
How to program applications for maximum performance . . . . . . . . . . . . . . . . . . 13
Tuning Servers for Maximum Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Is your server being overloaded? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Is your server doing unnecessary work? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Hardware recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix A: Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix B: Resources for additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Introduction
Domino™ provides many ways to build dynamic Web sites and applications. Navigators,
layout regions, programmable fields, and hide-when formulas give developers a wealth
of options for building complex Web pages that are dynamically generated. However, as
the complexity of a Web application increases, the processing and calculation required
by the server increases, which can affect performance. In addition, Domino provides
many services and functions as a Web application server, from replication to e-mail to
clustering. As the demands on a server increase, the increased processing load can
further compromise overall performance.

Performance tuning is an art
Since every server and application is different, the answer to the question, “How can I
make my Domino application run faster?” varies. There is no single means of
maximizing the performance of a Domino Web application or server, and no magic
setting like GO_FASTER = 1 that you can put in your NOTES.INI. The Domino
server performs so many functions that individual analysis of each server and
application is required to tune it appropriately. While Lotus® has many
recommendations and suggestions for maximizing performance — as detailed in this
white paper — fundamentally, it is the engineering skills of the Web developer,
webmaster, and server administrator that can best tune each application and server to
achieve optimum performance.

Tradeoffs are sometimes necessary
Maximum performance of an application does not always leave room for maximum
design elegance or maintainability. Developers often have to make tradeoffs between
speed and beauty. A page with 15 beautiful 256-color graphics is slower to load than a
simple page with one graphic. This means that Web developers must balance the need
for clean, simple functionality with the need for speed and make trade-offs where
necessary. It is important you consider all of the suggestions in this white paper in the
context of your individual application and design goals to reach optimum performance.

This white paper focuses on maximizing performance
This white paper focuses on what you can do to maximize the performance of Domino in
terms of:
Z Web applications, from the application development perspective
Z Overall server performance, from the server administration perspective
We start at the high level, providing performance considerations from the architectural
perspective, with a straightforward explanation of “what to do” and “why.” We then
progressively drill down into finer levels of detail, providing performance suggestions
for application developers at the form, column, and field level of your Domino Web
pages and for server administrators at the configuration and NOTES.INI level of your
Domino server.

Lotus Development Corporation Maximizing Application and Server Performance in Domino 1

This white paper is intended to be the central source of Domino performance tuning
suggestions from Lotus, and contains information compiled from many sources.
References to those and additional resources of performance information are located in
Appendix B.

The information here applies to 4.x versions of Domino, except where noted.
Note that in Domino 5.0, some NOTES.INI settings will be moved into and accessed
through the Domino directory. Every new release of Domino contains numerous
performance enhancements; note that the easiest solution may be to upgrade your
Domino server to the latest version for maximum performance.

2 Maximizing Application and Server Performance in Domino Lotus Development Corporation

Tuning Applications for Maximum Performance

How to design applications for maximum performance
The first step in examining or building a Web application is designing the architecture.
How many pages, views, and databases are involved? The table below contains
suggestions that should be considered at this architectural level. Many of the suggestions
revolve around a couple of major themes:
Z Indexing views takes time and processing power
Z Cached data is served faster than non-cached data
Note that some of these suggestions, although they directly affect application
performance, are often handled by the server administrator instead of the application
developer.

What to do Why Details

Minimize the number Views and folders, also known as
of views and folders. indexes, must be refreshed to
remain current. The more views
you have, the more work is
required by the server to refresh
these views.

Refresh indexes Indexing views takes time and For example, hidden views used
infrequently. processing power; refresh views for keyword lookups do not change
less often to reduce the load on very often but are still indexed
the system. regularly based on the default
settings. You can change the view
refresh interval through the
Refresh Index option in View
properties, Advanced options.

Minimize the creation Pages are served faster if they are See Appendix A for more informa-
of documents in busy already in the cache. Domino tion about caching in versions
databases. flushes the command cache if the 4.6.1 and higher.
database file is modified, such as
through the creation of new
documents.

Minimize or eliminate Authentication takes time. Domino Consider putting secure informa-
authentication in busy must look up names in the direc- tion in a separate database for
databases. tory, plus, certain commands are those users that need it, instead of
only cached when requested the main database that receives
anonymously. See the “Why” heavy traffic. See Appendix A for
section in the next row below for more information about command
additional effects of authentication. caching.

Continued



Use Anonymous for Domino caches the commands it The “Maximum cached
Default access when uses to display pages to anony- commands” setting in the Server
possible. mous users. When a registered document specifies how many
Web user is prompted for a name commands it stores; the default is
and password, Domino does not 128. See Appendix A for more
cache the commands for that information about caching in
session. versions 4.6.1 and higher.

Setting an application’s default
access to access levels other than
anonymous will require Domino to
authenticate users and therefore
not cache commands.

Use Secure Sockets SSL encrypted transactions slow SSL can be configured at the
Layer (SSL) only server performance. Choose SSL server level, in the Domino Direc-
when absolutely only when a high degree of tory, as well as in the Database
necessary security is essential. properties option “Web Access:
Require SSL Connection” (4.6).
Consider using a
separate SSL-only A test case of Notes port encryp-
database for secure tion on mail messages showed a
information performance decrease of 5–10%.
The impact could be larger
depending on your application.

Use scheduled Performing calculations using For example, if you have a catalog
agents for offline scheduled agents instead of page that does not change
calculations. dynamic events can achieve frequently, run a scheduled agent
significant performance gains by hourly or at night to update the
reducing the number of times a contents of the page rather than
page must be dynamically gener- use formulas to recalculate fields
ated. each time a user requests the
page.

Compact databases Compacting databases purges This is often performed by the
regularly. deletion stubs. Compact your UPDALL task, which is configured
application databases regularly by the server administrator.
during development (manual
compact) and production (UPDALL
task).

Minimize database Typically, you should only need to
accesses in scripts open a database or a document
and formulas. once in a script. Opening database
elements repeatedly is redundant
and will be time consuming.

Minimize the use of Prior to Domino 4.5, script libraries This suggestion does not apply to
script libraries (4.5 or used to result in somewhat slower releases 4.5.1 and higher.
earlier) application performance.


Server Configuration

Run web-triggered By default, Domino will execute Put the following setting on one
agents in parallel. agents triggered by web browsers line into the server’s NOTES.INI
one at a time (serially). Configuring file:
Domino to run agents in parallel
may improve your application DominoAsynchronizeAgents=1
response time.
Make sure that your application
design accommodates agents
running in parallel.

Enable caching of By default, Domino will not allow Put the following setting into the
dynamic pages. any dynamic pages that contain server’s NOTES.INI file:
formulas to be cached, since the
resulting values could quickly DominoAnalyzeFormulas=1
become outdated. However, you
can configure Domino to do intelli- For more information on this
gent caching based on the volatil- feature, see Appendix A. This
ity of the formulas used. setting will be set to 1 by default in
Domino 5.0.

Slightly increase disk To optimize response time, In the HTTP Server section of the
cache for images and Domino stores image files and file Server document, change the
attachments. attachments in the file cache settings in the following fields:
directory named dominocache (by • Cache directory
default). Since converting bitmap
• Garbage collection
images to Web image formats can
take time, caching the converted • Garbage collection interval
files on disk allows Domino to • Maximum cache size
return inline images more quickly.
• Delete cache on shutdown
However, creating a cache that is
gigantic can lock up system
resources; be conservative.

Increase memory To optimize response time, In the HTTP Server section of the
cache for HTTP Domino caches information about Server document, change the
commands, database HTTP commands, databases, and settings in these fields to adjust
designs, and users. users. Using these caches can the server’s memory cache:
alleviate the time it takes to map • Maximum cached commands
pages and authenticate users.
• Maximum cached database
designs
• Maximum cached users

Continued



Increase view buffer Large views take longer to display. Increase the setting for the
on server. Caching these views in a larger NSF_BUFFER_POOL_SIZE
view buffer will speed variable in the NOTES.INI file.
performance, instead of forcing This setting determines the
the server to read the view from maximum size of the cache for
disk. storing views (in bytes). It can be
increased to up to ¼ the physical
memory for large views or many
views. We don’t recommend
increasing it beyond ¼ the physi-
cal memory of the server. See the
“Does it take a long time to display
views?” section for more
information.


How to lay out pages for maximum performance
Domino provides many ways to lay out pages, using both HTML and Domino database
constructs such as forms and fields. This section focuses on approaches to laying out the
appearance of a page using static elements. The next section summarizes ways to design
forms for maximum performance.


Use the “HTML” field. When Domino encounters a page Note that you must generate
that contains a field named values for the values that Domino
“HTML,” Domino reads the value would otherwise calculate, such as
of the HTML field and sends the author and creation date, because
data to the browser without Domino passes the document to
performing any computations. the browser without any
Therefore, it is the fastest way to pre-computing or other Domino-
display Web pages. The HTML generated data.
field produces results that are
similar to the form property “For
Web Access: Treat documents as
HTML,” but gives better
performance.

Minimize the use of The more colors you use, the Limit bitmap graphics to 16 colors
256-color bitmaps. larger the size of the graphic, and and use low-resolution (72 dpi)
the more time required to transmit images for smaller files and better
Keep image file sizes the page. performance across multiple
as small as possible. platforms.

If you use 256-color bitmaps, use
no more than one per form and
use the Lotus color palette to
create the bitmap.

Store graphics in their Domino 5.0 stores graphics in their If you are upgrading a Domino 4.x
native format (R5 native image format (i.e. GIF, application, you will need to
only). JPEG), which greatly improves re-insert the graphics in order for
performance. In previous releases, them to be stored in their native
images were converted to bitmaps format. However, keep in mind that
when stored in a Domino those graphics would not be able
database, which required conver- to be viewed from a Notes™ 4.x
sion back to GIF format when client.
those bitmaps were delivered to
the Web. In 5.0, no conversion
occurs when a graphic is already
stored in its native format, greatly
reducing overhead.

Continued



Store images in Caches images, so performance is Use passthru HTML to access the
server’s file system better than imported or pasted image using syntax such as <IMG
(4.6 or earlier only). images for frequently used pages. SRC="banner.gif">. Images must
Uses server disk space more be maintained on every server that
efficiently than imported or pasted uses the images.
images because one image can be
used more than once.

Store images in a This configuration causes Domino 1. Create a view to list the
graphics library to cache images, so performance images.
database as attach- is better than imported or pasted
ments in documents. images for frequently used pages. 2. Then, use passthru HTML and
URL commands to open a
This configuration also uses document from a view by the
key name.
server disk space more efficiently
than imported or pasted images
3. Open the image which is an
because one image can be used attachment in that document.
more than once.
The tag below displays the image
in the “Animation” view using the
key “gifs” in a different database
on the same server.

<IMGSRC="/webimage.nsf/animati
on/gifs/$file/flag.gif">

How to design forms for maximum performance
Dynamic pages in Domino are usually produced using forms. Forms provide the ability
to programmatically calculate content at many different levels, right down to individual
paragraphs and fields. The suggestions below focus on ways to design forms for
maximum performance. These suggestions embody some general themes that will help
guide you in designing your forms for maximum performance:
Z The more calculation required (through formulas, subforms, etc.) the slower
the page



Minimize the use of Each formula Domino must calcu- See the Alternatives to using
formulas. late when opening a page slows formulas section below.
your application down.

Also, when an @function exists
on a page (that is, on a form,
document, view, or navigator),
by default Domino doesn’t cache
the commands used to display
the page.

Simplify formulas. Complex formulas and those that
use @DbLookup and @DbColumn
require more processing time.

Use cache-able Some functions, depending on the See Appendix A for details on
formulas on popular currency of their data, are not caching in Domino.
pages. cached.

Use JavaScript. JavaScript is evaluated on the JavaScript is commonly used for
client, as opposed to formulas or field input validation (e.g. Did the
scripts that are evaluated on the user enter the date in the appropri-
server. This lightens the server ate format?). This is more efficient
load and can increase than using Domino’s field-based
performance. input validation which requires a
round-trip to the server.

Don’t use field names Domino assumes that “HTTP_” This causes Domino to search for
that start with indicates a CGI environment any and all CGI environment
“HTTP_”. variable. variables in a page, which slows
performance.

Minimize the number Each field is calculated when a After your design is complete,
of fields. document is opened, refreshed, or be sure to remove any blank,
saved. unused fields.

Minimize the use of Shared fields open slightly slower Architecturally, shared fields are
shared fields. than single-use fields. on a different note and Domino
must make extra internal function
calls (a NoteOpen) to get the
value of the shared field. One
NoteOpen call to get the
document, one to get the form and
one to get each of the shared
fields.

Minimize the use of Loading subforms requires calcu- Architecturally, subforms are very
subforms. lations which can slow the similar to shared fields. See
opening of documents slightly. above.

Continued



Minimize the number Computed fields require additional For example, if you have two
of computed fields. processing and can slow computed fields whose values are
performance. supplied by a potentially slow
formula such as @DbColumn, use
one computed-for-display field to
collect the data, and compute the
other fields from the computed-for-
display field.

Use double brackets When specifying a result page in a See the Redirection URLs section
around redirection $$Return field or a WebQue- below.
URL’s. rySave agent, use double brack-
ets around the URL (if the page is
on the same server) for faster
performance.

Redirection URLs
When a $$Return field or a WebQuerySave agent generates a URL to display the next
page, the sequence of events is:
1. The browser submits the HTML form to the Domino server.
2. The server evaluates the $$Return formula or runs the WebQuerySave agent to
produce the redirection URL — for example, “[mydb.nsf/view?OpenView]”.
3. The server sends the redirection URL back to the browser.
4. The browser accepts that URL as input and requests the URL from the server.
5. The URL goes back to the server to process the request.
6. The server sends the result of that request back to the browser.
The process described above involves two round trips from the browser to the server. If
the redirection URL references a database on the same Domino server, you can avoid the
extra trip back to the server (and therefore increase response time) by using double
brackets “[[ ]]” around the URL.
The server recognizes this as an internal redirection URL and the transaction sequence
becomes:
1. The browser submits the HTML form to the Domino server.
2. The server evaluates the $$Return formula or runs the WebQuerySave agent to
produce an internal redirection URL — for example,
“[[mydb.nsf/view?OpenView]]”.
3. Before sending the URL back to the browser, the server recognizes the URL as
an internal redirection URL, evaluates the request, and sends the results of that
request back to the browser.


Alternatives to using formulas
Instead of… For maximum performance, use…

Formulas JavaScript. JavaScript runs in the browser, reducing server load.

Hide-when formulas • A computed subform.
• A hide-when condition property such as “Hide when editing” or
“Hide when reading.”
• Create two different versions of a form.

If you have Web-only or Notes-only forms (or other design
elements like views and navigators), use the Design Properties
box to hide them from the inappropriate audience. Give both
design elements the same alias name so you can use that alias
name in formulas. For example, if you create views named Notes-
Main and WebMain and assign them each the alias
“Main,” you can use the alias name in a formula, such as
@Command([OpenView]; “Main”). Domino presents the
NotesMain view to a Notes client, and presents the WebMain
view to a browser client. This technique gives better performance
than multiple hide-when conditions or computed subforms.

Field formulas Formulas in form events where appropriate. This enables you to
easily control which formulas are calculated at which event, such
as formulas that should only execute when a form is opened or
closed. Field formulas are calculated whenever the page is
refreshed, saved, or opened, etc.

Lookup formulas Use profile documents to store specific information across a
database. For example, the Release 4.6 mail templates
(mail46.ntf and mailc46.ntf) use profile documents to collect
calendar and schedule information, such as when a user will be
out of the office and who can access the user’s mail file. Profile
documents are useful for storing user-specific information in a
database.


How to design views for maximum performance
Many of the suggestions below revolve around a few major themes:
Z Indexing views takes time and processing power
Z Smaller views are faster views
Z The more calculation required, the slower the page

Minimize the use of Each formula Domino must calcu- Instead, place the formula on a
formulas in columns. late when opening a page slows form, and store its result in a field
your application down. @DB* to be displayed in the column.
lookup formulas are particularly
taxing. Write lookup formulas so that the
formula calculates only when the
field calculates. For example:

@If(@IsDocBeingLoaded;
@Unavailable; @DBColumn())

Remove all unneces- Each column is calculated when a After your design is complete, be
sary columns. view is opened or refreshed. sure to remove any blank, unused
Smaller views are faster views. or unnecessary columns.

Minimize the use of Cascading views requires the
cascading views. screen page to be redrawn on
each mouse click.

Do not use Form Due to the architecture of Domino, Use computed subforms instead.
formulas. computed subforms are faster.

Avoid time-sensitive Time-sensitive formulas recalcu- Using scheduled agents to update
column formulas that late each time a Web user works the view might be an alternative to
use @functions such in the view — for example, when a provide the same functionality
as @Now, @Created, Web user opens, scrolls, while improving view response
and @Modified. collapses, or expands the view. time.

Do not allow When a document appears in
documents to appear multiple categories, the size of the
in multiple categories. view index increases, causing the
view to open and refresh more
slowly.


How to program applications for maximum performance
Formulas, LotusScript®, and Java represent just a few of the ways you can program your
Web applications using Domino. Below are ways you can maximize the performance of
your applications that use formulas and LotusScript.

Formulas

Use @ClientType instead of It’s a simpler calculation, Another alternative for this
@UserRoles (4.6 or higher). and thus faster. functionality is to use the field
and text checkbox properties
Hide From Notes and Hide
From Web Browser.

Use column numbers instead of When you use a column The tradeoff in referring to
field names when using name, Domino must column numbers is that it is
@DbColumn or @DbLookup. compare the string you harder to maintain; any
request against the list of change to the order of
all column names, which is columns in a view can cause
slower than going directly miscalculations in your
to the column specified by formulas.
the column number.

Use the Cache argument Cached data is served
whenever possible when using faster than non-cached
lookup formulas @DbColumn, data.
@DbCommand, and @DbLookup.

Perform lookups on hidden views Smaller views are faster Two ways to minimize the
that have a minimum amount of views. data in the view is to use
data. substrings or to concatenate
strings in one column.

Speed up multiple-value lookups Write the lookup formula to
by creating a lookup view that parse the returned data into
combines all the needed values in the appropriate fields.
one column.

Avoid redundant lookups in a Fewer calculations Set the temporary variable
formula by setting a temporary provides better once, and then refer to the
variable for a returned value. performance. variable for the rest of the
formula.

Use LotusScript GetView, Search, This applies to processing
and FTSearch methods instead of small groups of documents
formulas. (i.e. less than 15 percent of
all documents in the
database).


LotusScript

Use back-end classes Back-end classes do not For example, avoid using the front-
instead of front-end need to manage or process end NotesUIDocument class
classes. UI effects, and thus are faster to do many field updates. The back-
than the front-end classes. end NotesDocument class is much
faster and allows you to assign data
types (including rich text) and
to add new (hidden) fields. The front-
end class allows you to update only
fields that already exist on
the form, and it allows you to
insert only text in the field, as
@Command([EditInsertText]) does.

Use For loops instead of For loops are faster than Do In the following example, the first
Do loops. loops, because the condition fragment runs 60 percent faster than
that bounds the Do loop must the second fragment.
be evaluated at each iteration
of the loop. Fragment A

For y=1 to 15000
z=z+1
Next

Fragment B

Do
z=z+1
y=y+1
Loop While y<= 15000

Use Forall instead of For Forall loops are faster in Forall is 75 percent faster than For
in referencing array handling arrays than For when referencing all elements in a
elements. loops. 1-dimensional array, and 50 percent
faster when referencing elements in
a 2-dimensional array. Similar
performance improvements occur in
arrays with higher numbers of
dimensions.

Continued



Simplify If statements. Reducing the number of This statement always results in both
conditions that need to be conditions being evaluated.
evaluated will reduce the time
required to execute a script. if a=x and b=y

This statement runs 40 percent faster
than the previous example because
the second condition evaluates only
if the first is true.

if a=x then if b=y

Use Search and This applies when updating between
FTSearch methods 1 and 15 percent of documents in a
instead of the GetView database.
method.

Avoid mixing variable Casting, or matching variable The following example shows
types (implicit casting) types in operations, slows implied casting, where LotusScript
in operations. down script performance. has to convert data types to perform
Where possible, avoid the operation. The implied casting
casting by performing opera- slows this code down by 40 percent.
tions with like variables. If this
is impossible, use explicit sub initialize
dim a as single
casting rather than implied dim z as long
casting to improve z=3
performance. a=1.0
z=z+a
end sub

Use the ColumnValues Using the ColumnValues The ColumnValues property returns
property of the Notes- property is about 10 percent an array of that document’s column
Document class for faster than getting a handle to values in the document’s parent
lookup scripts. a document and using the view.
extended class syntax — for
example, x=doc.fieldname.

Use a backslash () for Regular division, using the
integer division instead forward slash (/), always
of a forward slash (/). returns a float, even if
operands are integers. Use a
backslash () for integer
division where you do not
need or want a floating point
result.

Continued



Minimize the use of Because a variant can The effect of explicit type casting is
Variant types. contain many different types particularly noticeable when perform-
of data, the LotusScript ing integer operations, where an
engine needs to interpret the iteration with a declared integer can
type of data before operating perform up to 200 percent faster
on a variant variable. Assign- than the same operation with a
ing explicit variable types declared variant. The difference is
results in faster code. less dramatic with string operations.

Disable AutoReload The AutoReload option (on by Before your script does any updates,
when using UI classes. default) will update a use the following statement to
NotesUIDocument object disable AutoReload:
every time a change is made
to the corresponding back source.AutoReload = False
end NotesDocument object.
After you disable AutoReload, it
If you are making many
remains disabled until your script
changes to a NotesDocument
enables it again using this syntax:
object, turn AutoReload off
to eliminate the extra source.Reload
processing required to update
the corresponding NotesUI-
Document object.

Continued



Read entire files at File operations are faster if In the following examples, code
one time instead of you read an entire document, fragment A runs about 600 percent
incrementally. then operate on individual faster than code fragment B.
records, rather than if you
read one line at a time. Fragment A
Buff$=Input$(Lof(1),1)
Do
In Domino R5, the Lotus j=Instr(i,buff$,chr$(13))
Script string variable limit If (j<>0) Then
has been increased to 2 Y$(myindex)= _
Mid$(buff$, i, j-i)
gigabytes. The string limit I=j+1
in previous releases is 64
kilobytes of memory (32,000 Else
2-byte characters). Y$(myindex)= _
Right$(buff$,Len(buff$)-i)
End If

Myindex=myindex+1

Loop While (i<len(buff$))
And (j<>0)

Fragment B

Do
Input #1, y$(myindex)
myindex=myindex + 1
Loop While eof(1) = FALSE
Continued



Avoid using unneces- Storing data in arrays rather In the following examples, code
sary arrays (i.e. Tempo- than in non-array variables fragment A runs twice as fast as
rary arrays used for can degrade performance up code fragment B.
calculations or data to 50 percent. If possible,
manipulation) avoid using arrays to store Fragment A
temporary or intermediate
data. for i=1 to 100
sum = sum + x(i)
next
Note: Domino 5.0 contains t(1)=sum
new array functions that may
simplify array operations: Fragment B
ArrayAppend, ArrayGetIndex,
for i=1 to 100
ArrayReplace, and Fulltrim. t(1)=t(1)+x(i)
Using these functions in Next
place of multiple lines of
manual code that perform the An alternative to using an array of
same purpose will be faster. strings would be to create a single
string of all of the strings in the array,
using a delimiter like a carriage
return. Then use INSTR to search for
a particular string.

Minimize the use of Compute array size before
Redim. declaration if possible.

Avoid copy and append For example, the operation
operations. x$=x$+"a" is expensive in
terms of performance.

Continued



With n-dimensional Index the first bound of an
arrays, index the last n-dimensional array with the inner-
bound in the outermost most loop, and index the last bound
loop. with the outermost loop. In the
following examples, code fragment A
runs 400 percent faster than code
fragment B.

Fragment A

for y=0 to 2
for q=0 to 5000
z=z+x(q,y)
next
next

Fragment B

for q=0 to 5000
for y=0 to 2
z=z+x(q,y)
next
next
Continued



Compare integers Comparing strings is slower Code fragment A is 50 percent faster
instead of strings. than comparing integers. than code fragment B.

Fragment A

If (Asc(x$) = Asc("A"))

Fragment B

If (Left$ (x$, 1) = "A")

Code fragment C is 30 percent faster
than code fragment D.

Fragment C

If (Asc(Mid$ (x$, 1, 1) =
"A"))

Fragment D

If(Mid$(x, 1, 1)= "A")

In checking for a null string, code
fragment E is 30 percent faster than
code fragment F.

Fragment E

If (Len (x$) = 0)

Fragment F

If (x$ = "")

Continued



Use the GetNthDocument is designed Fragment A is significantly faster
GetNextDocument to retrieve documents in than Fragment B.
method instead of varying locations in a collec-
GetNthDocument tion; if you are iterating Fragment A
method when iterating through a collection one by
through collections. one, GetNextDocument is set doc=
collection.getfirstdocument
more efficient. while not doc is nothing
Set doc= _
collection.getnextdocument
(doc)
wend

Fragment B

for x = 1 to
collection.count
set doc=
collection.getnthdocument
(x)
next x
Use the NotesDatabase Depending on the application, You can use the existing View Selec-
class Search method using the NotesDatabase tion formulas you have in your views
instead of the Search method might be just as the formula$ parameter for the
NotesView class as effective. Instantianting a Search method.
GetAllDocumentsByKey view object and opening a
method. document from a view keeps
summary information resident
in memory, which is overhead
that can decrease perform-
ance.


Java

Put java classes that are Note that the base class must appear
loaded frequently first in the list of classes.
towards the top of the
class list (as soon as
possible after the base
class).

Call the recycle function This function will free An unreferenced object is any object
periodically memory used by that does not have a variable or
unreferenced Domino objects. another object that refers to it.
The LotusScript Unreferenced objects can result
interface performs this task when an object variable goes out of
automatically. scope or is assigned to another
object.

In LotusScript, objects that become
unreferenced are immediately
destroyed. While Java as a language
does have its own “garbage collec-
tion,” this method does not clear the
memory used by the underlying
Domino objects.


Tuning Servers for Maximum Performance
The tables below contain suggestions that most often involve configuring your Domino
server through the directory and NOTES.INI. Each section begins with a question related
to common configurations or problems. If you answer “yes” or “maybe” to any of the
questions, follow the suggestions in that section to tune your Domino server for
maximum performance.
You will find many of the suggestions below revolve around a few major themes:
Z Focus your server on its most important tasks, and disable services that you are
not using
Z Many caches and buffers can be tuned depending on where your problems are
Z The Indexer (Updall) task is one of the most time-consuming tasks. Pay close
attention to factors that affect the Indexer such as NOTES.INI settings, view
sizes, view caches, etc.

Is your server being overloaded?
If you need to seriously scale Domino to high user loads, use Domino partitioned servers
and clustering to divide the load and take advantage of high end hardware configurations.

Is your server doing unnecessary work?
Many server tasks are started by default. If you don’t need a task, don’t start it!
Calendaring & Scheduling can require up to 15–20% of a server’s CPU. Some server
tasks you may be able to disable are listed below. Note that the AdminP task is necessary
if you are running the Certificate Authority application for SSL or using Web
Administration.

Task name Turn it off IF…

Router You are not using the server for electronic mail or workflow.

Calconn You are not using the server for calendaring and scheduling.

Sched

AMgr You do not run scheduled agents. Agent Manager is not required
for WebQueryAgents.

Collector You do not want to automatically track server statistics at regular
intervals. Note that you can still generate server statistics on
Reporter demand.


Does it take a long time to display views?

Increase the view Large views take longer to display. Increase the setting for the
buffer on the server. Caching these views in a larger NSF_BUFFER_POOL_SIZE
view buffer will speed variable in the NOTES.INI file. This
performance, instead of forcing the setting increases the maximum
server to read the view from disk. size of the cache for storing views
(in bytes). It can be increased to
up to ¼ the physical memory for
large views or many views. We
don’t recommend increasing it
beyond ¼ the physical memory.

Once you increase it you should
see a decrease in I/O activity.
Also, watch the statistics:

Database.BufferPool.Maximum

Database.BufferPool.Peak

Database.BufferPool.
PercentReadsInBuffer

Note that the BufferPool.Peak
value can exceed the
BufferPool.Maximum value slightly
due to the algorithms used to
calculate the value.

Does it take a long time to access databases?

Increase the This setting determines the Domino flushes the cache
NOTES.INI setting maximum number of database every 5 seconds. The default
NSF_DBCACHE_ open/close handles in the cache. setting of entries is
MAXENTRIES. You can increase this up to 1872 MAX(25, NSF_BUFFER_
entries. POOL_SIZE/300KB). Once you
increase it you should see a
decrease in I/O activity.

Decrease the size of Large databases require more I/O
the database, and use more memory, taxing
perhaps by archiving precious resources.
old or little used parts.

Continued



Upgrade the I/O Because large databases require
subsystem or add more I/O and use more memory;
more memory. increasing these will improve the
performance.

Distribute access of a Split users across multiple replicas Put another replica of the
highly used database to improve performance instead of database on a clustered node.
across replicas. burdening one database and
server with all users. If you are using a single server,
put the highly used database on a
different hardware array and refer
to it via a database link.

Use clusters. Domino has superior clustering Clustering provides a means for
technology that provides high load balancing heavily used
availability and failover for heavily servers and/or databases. Key
used servers or databases. parameters include
Server_Availability_Threshold and
Server_MaxUsers.

Do you have a uni-processor system?

Increase the This setting sets the maximum Domino automatically deletes
SERVER_MAXSESSIONS number of Notes client sessions/tasks that have been
in the NOTES.INI (if running sessions allowed concurrently. idle for more than 10 seconds.
in a mixed Notes and By default, it is unlimited. You
browser client environment). might want to limit the number
of Notes client sessions
allowed to provide better
service.

Do not increase the number More indexers will not improve
of Indexer tasks. performance with one proces-
sor. Keep the default at 1.

Do not increase the number More replica tasks will not
of Replica tasks. improve performance with one
processor. Keep the default at
1.

Threads
An increased number of threads does not always provide increased performance. Blindly
increasing the number of threads will not increase performance because all of those
threads could still run into a system resources bottleneck; while there might be more
threads available, there would not be more system resources available, and users will not
see an increase in performance.


The effects of increasing the number of threads
An increase in the number of HTTP threads does not affect CPU utilization, but it does
increase the use of memory and I/O activity. Lotus tests have shown there can be a
degradation in performance and an increase in memory consumption if there are more
HTTP threads defined than are needed. You should therefore set the number of threads
carefully.

How to set the correct number of threads
Determining the optimum number of HTTP threads takes some server load testing and
tuning. First, start by setting the number of HTTP threads (the “HTTP Threads” setting in
the Server document) to 10% of the estimated number of Web users. For example, if you
anticipate 200 Web mail users, start by setting the maximum number of threads to 20.
Then, simulate the user load and check the Domino.Active.Threads.Peak statistic by
typing the following in the Domino server console:
show statistic domino.threads.active.peak
Keep in mind that this peak number will not exceed the maximum number of threads
allowed. Determine if your server is reaching the maximum number of threads set by
comparing this statistic to the setting for the maximum number of threads.
Once you have determined the average peak number of threads used, set the maximum
number of threads in the server document to a value slightly above the peak value. This
will be the optimal setting for maximum performance of your Domino server.

Do you have an active, large scale Domino Server?

Increase the NOTES.INI The first parameter sets the In heavier utilized environ-
parameters SERVER_MAX_ maximum number of NRPC ments (a guide is 1000-2000
CONCURRENT_TRANS & transactions that should be active users) set the param-
SERVER_POOL_TASKS executed by the Domino Server eters to SERVER_MAX_
simultaneously. The second, CONCURRENT_TRANS=1000
governs the number of IOCP and SERVER_POOL_
"worker" threads to handle the TASKS=100.
active sessions.

Increase the number of Multiple processors can handle A good guideline is to set the
Indexer tasks. more than one indexer task. number of indexers to the
Views will be more likely to be number of CPUs minus one.
up to date. For example, if your server has
4 processors, use 3 indexers.
Be careful not to run too many
indexers, which will prevent
other server processes from
getting to the CPUs.

Continued



Increase the number of Multiple processors can handle A good guideline is to set the
Replica tasks. more than one replica task. number of replica tasks to the
Replicas will be better number of CPUs minus one. For
synchronized. example, if your server has 4
processors, use 3 replica tasks.

Is Your CPU saturated? Is the Indexer a bottleneck?

See “Increase the number of See above. See above.
Indexer tasks” in the previ-
ous section

Increase the NOTES.INI Increasing this value will mean This setting determines the
setting the indexer will run less minimum amount of time that
UPDATE_SUPPRESSION_ frequently, freeing up server must pass before the indexer
TIME. resources. runs again. The default is 1
minute. The unit for this setting
is minutes.

Increase the NOTES.INI Increasing this value will mean This setting determines at what
setting the indexer will run less number of view update
UPDATE_SUPPRESSION_ frequently, freeing up server requests the view will be
LIMIT. resources. updated and the indexer will be
run. LIMIT overrides TIME
setting if LIMIT number of
update requests are received.

Increase the NOTES.INI Increasing this value will cause This setting is undocumented
setting the indexer to update hidden and unsupported. The default is
UPDATE_NAB_ Name & Address views less 1 minute. The unit for this
SUPPRESSION_ TIME. often. setting is minutes. LIMIT
overrides TIME setting if LIMIT
number of update requests are
received.

Set the NOTES.INI setting This setting will disable the This setting is undocumented
UPDATE_NAB_VIEWS_ automatic updating of hidden and unsupported.
DISABLE equal to 1. views in the Name & Address
Book.

Set the NOTES.INI setting This setting will not force an This setting is undocumented
SERVER_NAMELOOKUP_ immediate rebuild of namespace and unsupported in 4.5x. This
NOUPDATE equal to 1. views (such as those used for will be the default behavior in
looking up addressees in e-mail) Domino 5.0.
if they are out of date. The
indexer will still update views in
background. This setting
provides faster name resolution.


Hardware recommendations
Software performance is directly related to the speed of the hardware it runs on.
Hardware speed in Domino is most visible in the following ways:

Processors affect:
Z Indexer speed
Z Replicator speed
Z Number of maximum possible database transactions
Z Number of add-ins that can run in parallel

Disk access affects:
Z Number of maximum possible database connections
Z Speed of database and view opening

Memory affects:
Z Number of maximum possible simultaneous Notes client connections (sessions)
Z Size of caches
Z Server add-in task performance (less paging to disk)
Many of the suggestions below revolve around these themes as well.

Spread databases and Like multiple processors, multiple For example, consider putting the
programs across disks can do more work (I/O) in page file on one disk, the Domino
physical disks. parallel. executable on a second disk, and
the log file on a third.
Use faster disk drives. Database accesses can be I/O You can increase drive speeds
intensive. from 5,400 rpm to 7200 rpm. SCSI
is better than IDE.
Use RAID striping/ This will speed up database Use an 8K stripe (on Digital
mirroring (e.g., RAID access times, which can be I/O systems) or a 16K stripe (on IBM®
1-0) and/or increase the intensive. Netfinity®).
stripe size.
Use disk controllers This hardware will reduce Move from EISA-based systems
with non-volatile disk contention on databases. and controllers to PCI-based
caches. systems.
Check your network Upgrade from 10Mbps cards and
bandwidth. networks to 100Mbps ones.
Use TCP/IP. TCP/IP is a scalable protocol,
whereas older protocols like
NetBIOS and SPX are not.
Log to text files or turn Logging can drain performance.
off logging completely if Logging to Domino databases is
possible. more resource-intensive than
logging to text, and logging to both
formats is never necessary.


Appendix A: Frequently Asked Questions

Applications
What’s faster: LotusScript or Java?
In terms of performance and functionality, Java and LotusScript are comparable. There
are some differences between the two languages in terms of architecture that may affect
the performance of your application, depending on its design:
Z If your application will be multi-threaded to handle complex processing, use
Java. Java has a thread model built into the language and allows you to spawn
threads. LotusScript does not support multi-threading.
Z LotusScript agents run on the server, while Java agents run on the browser client.

What’s faster: LotusScript or formulas?
Formulas that need only a single @function, such as @Command([FilePrint]), are more
efficient and perform better than scripts that do the same thing. Formulas also perform
better than script when you want to update more than 15 percent of the documents in the
current database and the logic is simple enough to produce with @functions.
Scripts are often more efficient than complex formulas that use many @functions.
LotusScript accesses documents more efficiently and quickly than a formula that uses
@functions to “touch” many databases or documents.
The LotusScript user interface (front-end) classes use the same underlying code as their
equivalent @commands, so LotusScript won’t perform better than the formula language
when you use these classes. The database (back-end) classes, however, use different code
and perform more quickly than the equivalent @functions.

What are the performance considerations in upgrading older applications?
In upgrading applications from versions 3.x to 4.x, there are two main areas where you
can increase performance:
1. Convert 3.x hidden fields to form events
If your application was created in Release 3.x, it may include forms with
hidden fields containing formulas that process a document when it’s opened
or saved. To improve the performance of the application, convert the
formulas to LotusScript, and use the PostOpen and QuerySave form events.
2. Update formulas
Later releases of Domino contain many new and improved @functions.
Evaluate whether to incorporate changes to @functions into existing
applications. For example, if a Release 3.x application contains a long
formula to add a set of numbers, you can now use @Sum to simplify the
formula.


Appendix B: Resources for additional information

Resource Description Location
Lotus Performance Zone A central web page listing www.lotus.com/performance
performance information
resources.
Optimizing server Platform specific suggestions The Notes Administration
performance on performance tuning. Help database
(HELPADMN.NSF)
Optimizing Your Server An article that provides www.notes.net/today.nsf
Performance: Part 1 details on server performance
analysis, including bench-
By James Grigsby, Carol marking tools. This article
Zimmet, and Susan Florio also details examples of
server performance tests
performed at Iris on port
encryption and
NSF_BUFFER_POOL_SIZE.
Optimizing Your Server An article that provides www.notes.net/today.nsf
Performance: Part 2 details on tests of CPU
scaleability.
By James Grigsby, Nirmala
Venkatraman, and Susan
Florio

Best Practices Guide www.lotus.com/bpg
NotesBench Consortium site Published benchmarks and www.notesbench.org
test results for Domino
servers by different hardware
vendors. The NotesBench
Consortium is an
independent, non-profit
organization dedicated to
providing Domino and Notes
performance information to
customers.


Appendix C
This article resides in “Iris Today,” the technical Webzine located on the http://www.notes.net
Web site produced by Iris Associates, the developers of Domino and Notes. Please visit Notes.net
to obtain the latest version of this article as well as other related articles.

Expanded Command Caching introduced in Domino 4.61
by Andrew Wharton

Since its initial release, the Domino HTTP server has had the ability to keep a volatile,
in-memory cache of requested HTML pages called the Command Cache. The very nature
of a dynamic Web applications server would preclude the caching of all Web pages.
Some Web pages, however, are “static enough” that they can be reused when the same
URL or command is issued from a browser. This section describes how the Command
Cache works so that you can design applications that take advantage of its capabilities —
and the performance gains it provides.

Command Cache fundamentals
The Command Cache saves Web pages in memory in the event that the same Web page
URL will be requested in the future, and that the cached page will still be valid to serve
for that URL. To do this correctly, the cache must understand the nature of the page
being saved, and it must know how to determine if that page is still valid for serving.
While the Command Cache has been part of Domino since its inception, the role of the
Command Cache is continually expanding as we make it more and more capable of
understanding pages and determining their validity.

Caching URL commands
The following types of Domino URL commands (and the HTML that they generate) are
currently the only candidates for the Command Cache:

?OpenDatabase
?OpenView
?OpenDocument
?OpenForm
?ReadForm


Other commands (for example, ?EditDocument) are not considered for caching. Domino
only serves pages from the Command Cache if the URL request exactly matches the
URL of the cached pages, even though Domino URL syntax allows multiple ways to
specify the same URL command (by using replica IDs instead of database names, or
view names instead of view UNIDs).

Caching @functions
Determining the algorithm to make an accurate and timely decision as to which Web
pages are cacheable is one stumbling block to making a very useful caching system.
In 4.6, we considered the very presence of @functions (among others) too volatile,
and thus, did not consider any pages with @functions as candidates for caching.
Unfortunately, this meant that many Web pages could not take advantage of caching
and the performance gains that it provides.
In 4.61, much has changed. As part of the ongoing effort to provide performance
improvements in the Domino server, we now provide the ability to cache Web pages that
contain @functions. This is a very simple statement with very powerful implications for
the Web site administrator, the Web application designer and the Web application user.
Domino 4.61 now has the ability to analyze all macro language (@function) formulas for
their dependencies through the Formula Analyzer. Rather than exclude all pages that
contain any @function formulas from the Command Cache, the Formula Analyzer
intelligently examines the formula on the page and decides its level of volatility. By
doing this first, Domino can decide immediately whether the command is too volatile to
be cached (for example, the Web page contains @Now) and, perhaps more importantly,
under what conditions a cached command becomes invalid.
The logic for these caching schemes is based on very conservative thinking. In all cases
where the slightest bit of ambiguity exists, Domino will not cache the page. We
considered the performance loss of re-rendering the resultant HTML to be a small
tradeoff to the possibility of sending out-of-date, incorrect, or inappropriate information
to the requesting user.
The Formula Analyzer is turned OFF by default in 4.61, meaning that any @function
will result in the page not being cached. To enable the Formula Analyzer, place the
following line in your NOTES.INI file:

DominoAnalyzeFormulas=1
It is important to note that without this setting, the Command Cache behaves exactly the
way that it did in 4.6; you will still get the benefit of command caching, just without the
expanded usefulness of caching Web pages where @formulas were used in the process.


Cache flags
When the Formula Analyzer examines a command invoking @formulas, flags are
assigned to that cache candidate based on the evaluation of the @formula(s), among
other things. The following flags are used by the Domino HTTP server to determine the
cache strategy, explained in the next section. (A cache candidate can and often does have
multiple flags.)

OffDb — The page uses data outside the current database. This includes the use of CGI
variables.

TimeVariant — The page uses time-variant data (such as @Now).
HadEffect — The page has an important side-effect (such as @DialogBox).

UsedEnv — The page uses the environment (NOTES.INI). This does not include CGI
variables.

UserVariant — The page is dependent on the user’s identity. This includes using any
data or design note that includes Read ACLs, Readers fields, Authors fields or controlled
access sections.

DesignUserVariant — The page is from a database that has protected design elements.

DbData — The page uses data in the database other than the referenced document. This
includes all views, embedded views in forms, and so on.

UsedDocId — The page uses the document’s ID.
UsedNewDoc — The page uses a newly-created in-memory note.
Unknown — The page does something that couldn’t be analyzed (such as executed
LotusScript).

Error — The page generated an error of some sort.

Cache strategy
Domino uses the cache flags to determine the cache strategy for a given command. A
cached command can have multiple cache strategies. The most restrictive strategy wins.
The strategy is stored with the command if it is cached, and is used to help determine
whether the command is still valid each time it is retrieved from the cache. The cache
strategies are:

DontCache — Don’t cache the response at all.
Document — Invalidate the cached response when the document changes.
DbDesign — Invalidate the cached response when the database design changes.

DbData — Invalidate the cached response when any of the data in the database changes.
OnlyAnonymous — Cache the response, but only serve it when the user is anonymous.


Any commands with the following flags are not cached (the DontCache strategy):
OffDb
TimeVariant
HadEffect
UsedEnv
Error
Unknown
UserVariant (if authenticated)
DesignUserVariant (if authenticated)
Here is an example of how command flags set the cache strategy. We will annotate the
cache flags Flag(flag) where flag refers to the flags above. The cache strategy will be
annotated as Strategy(strategy) where strategy refers to the strategies above. Using this
notation, cached commands are assigned a cache strategy that defines how the cache is
invalidated. This is illustrated by the following pseudocode:
Sub CACHESTRATEGY
CASE OPENDOCUMENT
CACHESTRATEGY = Document
If Flag(OffDb) or Flag(TimeVariant) or Flag(HadEffect) or Flag(UsedEnv) then
CACHESTRATEGY = DontCache //don’t cache
return CACHESTRATEGY //we’re done
End If
If Flag(UsedDocId) and Flag(UsedNewDoc) then
End If
If Flag(UserVariant) or Flag(DesignUserVariant) then
If USER_AUTHENTICATED then
End If //not authenticated
CACHESTRATEGY = CACHESTRATEGY + OnlyAnonymous //continue
End If
CACHESTRATEGY = CACHESTRATEGY + DbDesign //continue
If Flag(DbData) then
//remove Document strategy and add DbData strategy
CACHESTRATEGY = CACHESTRATEGY - Document + DbData //continue
End If
return CACHESTRATEGY
CASE OPENFORM
// etc.
End Sub


You are smarter than your server
The Command Cache does a good job understanding the page creation process and
automatically invalidating pages, but it is not perfect. Because of its conservative nature,
it errs on the side of not caching pages in order to guarantee the correctness of the page
returned. You may decide that certain pages can be cached where the server determines
that they cannot be. We’ve provided controls so that you can override the cache behavior
where appropriate. The following fields can control the use of the cache to some extent:

$CacheOptions — If the value of this field is the text string “0”, then the response is not
cached.

$CacheValid — The value of the numeric text string N will be evaluated and will
protect the response from validity checks for N seconds. This setting can be globally set
by using the NOTES.INI setting “DominoDefaultCacheValid=N.” The default for the
HTTP server is N=0.
The $CacheValid field lets you tell the cache that this page should be considered valid
for a certain number of seconds regardless of what Domino determines the cache strategy
to be. Consider a simple home page that is being continually edited. As this page would
be given the “Document” strategy, the cache entry would become invalid each time the
page is edited. You consider it acceptable that the home page is not continually updated
as a tradeoff for performance. You can communicate this to Domino by creating a
$CacheValid field on the document with a value of “180.” This means that the results of
the page should be considered valid for 180 seconds. After that time, the normal validity
checks will take place.

Viewing the cache strategy and flags for a page
If the NOTES.INI variable “DominoTraceCmdCache=1” is set, the cache strategy and
the cache flags will be included in the HTTP header information that is sent to the
browser when a page is served. To view this information, you can use a tool that displays
this information (such as a wire-sniffer) or download the following Java application
(9Kb) written by Bob Congdon at Iris. This tool is not a supported product; it’s just
intended to be a useful utility.
Make sure that CLASSPATH has “.” on it, and run the application by entering “java
SpyFrame” at the command line. While Bob developed the application using the JDK
1.1.1, it should run fine with JDK1.0x since it doesn’t use any JDK 1.1.1-specific
classes.
The following header information is sent:

X-DominoCmdCache-EvalInfo — Following this is a comma-separated list of flag
words (information pieces) that the Formula Analyzer set in the process of evaluating the
page (see above).

X-Domino-CmdCache-Strategy — Following this is a comma-separated list of flag
words that denotes the cache strategy that was assigned to the command based on the
inspection of the EvalInfo (see above).


X-Domino-CmdCache-ValidSeconds — This is the number of seconds that the
response will be assumed to be valid without the benefit of a validity check. This is the
time set in either the $CacheValid field of the DominoDefaultCacheValid NOTES.INI
variable.

X-Domino-CmdCache-CheckValid — This is the clock time that states when the
validity check will again be allowed.

X-Domino-CmdCache-DataMod — This is the recorded data modification date that is
used for the validity checking.

X-Domino-CmdCache-DesignMod — This is the recorded design modification date
used for validity checking.

Cache statistics
You can check the efficacy of your Command Cache by monitoring the following server
statistics:

Domino.Cache.Command.Count — This is the actual number of commands that are
contained in the Command Cache.

Domino.Cache.Command.MaxSize — This is the maximum number of commands that
can be cached. This is the number configured from the Server document in the Public
Address Book using the “Maximum Cached Commands” field.

Domino.Cache.Command.HitRate — This is the percentage-ratio of the number of
times a valid cache entry is found in the cache to the number of times the cache was
investigated for a cache entry.

Domino.Cache.Command.DisplaceRate — This is the percentage-ratio of the number
of times that a new cached command displaces an aged command to the number of times
the cache was investigated for a cache entry.


List of @Functions
The following is a list of @functions and the Eval flags that are set at compute time. If a
function is not listed here, safely assume that there is no associated Eval flag set. The
Eval flag Depends means that the evaluation of the entire formula will determine the
Eval flag set. If the @function says “Fallback,” that means that there is an evaluation that
is Web server-specific and this is the non-Web version. Its converse is “Web.”

@Accessed — OffDatabase,UsedDocId
@Certificate — OffDatabase
@Command - Web — Depends
@Command([Compose]) — Depends,DbDesign,OffDatabase
@Command([FileSave]) — HadEffect
@Created — UsedDocId
@DbColumn - Fallback — UserVariant,DbDesign,DbData,Unknown,Depends,
OffDatabase

@DbCommand - Fallback — Unknown
@DbCommand - Web — Depends

@DbLookup - Fallback — Depends,Unknown,DbData,DbDesign,UserVariant,
OffDatabase

@DbManager — DbDesign
@DbTitle — DbDesign
@DocumentUniqueID — UsedDocId
@Environment — HadEffect,UsedEnvironment
@GetDocField — DbData,UserVariant
@GetPortsList — UsedEnvironment
@GetProfileField — DbData,UserVariant

@InheritedDocumentUniqueID — UsedDocId
@MailEncryptSavedPreference - Fallback — UsedEnvironment
@MailEncryptSentPreference - Fallback — UsedEnvironment
@MailSavePreference - Fallback — UsedEnvironment
@MailSend - Fallback — HadEffect
@MailSignPreference - Fallback — UsedEnvironment


@Modified — UsedDocId

@NoteID — UsedDocId
@Now — TimeVariant
@PostedCommand - Web — Depends

@Random — OffDatabase
@Responses — DbData
@SetDocField — HadEffect,UserVariant

@SetProfileField — HadEffect,UserVariant
@TextToTime — TimeVariant
@Today — TimeVariant
@Tomorrow — TimeVariant
@Unique — None,Depends,OffDatabase
@URLGetHeader - Fallback — OffDatabase

@URLOpen - Fallback — OffDatabase,HadEffect
@UserAccess - Web — OffDatabase,UserVariant,DbDesign
@UserName — UserVariant

@UserPrivileges — DbDesign,UserVariant
@UserRoles - Fallback — DbDesign,UserVariant
@UserRoles - Web — DbDesign,UserVariant
@V3UserName — UserVariant
@ViewTitle — DbDesign
@Yesterday — TimeVariant

@Zone — TimeVariant


Maximizing application performance

More Related Content

What's hot (18)

Viewers also liked (9)

Similar to Maximizing application performance (20)

More from dominion (20)

Recently uploaded (20)

Maximizing application performance