Designing a Process application for increased performance can significantly
improve application efficiency and enhance the user experience. The
following guidelines provide general recommendations for optimizing
Process application performance:
- Minimize round-trips to the Content Platform Engine server
Performance
improvements can be achieved by minimizing the number of Remote Procedure
Calls (RPCs) to the Content Platform Engine.
Methods that fetch data or cause some action to occur typically cause
RPCs to the Content Platform Engine server.
In contrast, methods that get and set data are local to the object.
Similarly, minimize logging on and logging off from the Content Platform Engine.
- Minimize the amount of data transferred
Fetch the minimum amount
of data necessary by retrieving only the data that is needed to process
work. Eliminate the return of unnecessary system or user fields, and
cache static data (such as user information, and queue names).
- Optimize queries
Minimize the amount of data that is returned
for a query. Return only user fields (set query flags to avoid retrieving
system fields and helper data), if possible. Use filters and indexes
to further minimize the amount of data. Each element that is retrieved
has a different cost, as follows:
- Roster element: the least amount of data.
- Queue element: less data is transferred than for a Step element
(system fields describe the work item and its state).
- Step element: less data is transferred than for a work object.
- Work object: the most data transferred (contains all system fields
and user fields).
- Cache data
Cache retrieved objects when possible.
- Partition for multiple queues
Create distributed queues with
useful indexes and exposed fields.
- Optimize Roster, Queue, and Log usage
(See the following sections.)
Optimizing Roster Usage
All
work items are tracked through the roster and multiple workflow definitions
are contained in a roster. Only VWRosterElements and VWWorkObjects are
retrieved from a Roster query.
To optimize roster usage:
- Expose only infrequently updated fields. Exposed data fields on
rosters are more costly for updates.
- Set an optimal buffer size on the roster-related queries. For
example, consider increasing the buffer size (default is 50, maximum
is 200) to minimize round-trips to the Content Platform Engine server.
- Do not query work objects through the roster. Doing so causes
the application to access the database twice instead of once.
Optimizing Queue Usage
All
work for a particular step resides in a queue (the queue contains
the actual work object data). A queue can potentially contain different
types of work objects. When a queue is queried, VWWorkObjects, VWStepElements,
and VWQueueElements are retrieved.
To optimize
queue usage:
- Use the QUERY_LOCK_OBJECTS flag. Doing so avoids the necessity
of another RPC to check the lock status of an object (or to lock an
object). Using the flag also reduces lock contention.
- Set an optimal buffer size on the query. For example, consider
increasing the buffer size (default is 50, maximum is 200) to minimize
round-trips to the Content Platform Engine server.
- Partition, if possible, to use more than one queue.
Optimizing Log Usage
To optimize
log usage:
- Partition to use different logs for different workflows.
- Disable any logging options that you do not need. Doing so might
improve performance, but it also affects the Tracker. Do not use this
technique with Tracker.
- Manage log records. Use the vwlog tool to maintain logs. Use operating
system scheduling tools to periodically remove unused log records.
- Save log information in text files.
Optimizing Queries
To optimize
query usage:
- Set the appropriate query flags to return onlyuser fields from
Roster, Queue, and Log queries. For example, set the query flags QUERY_GET_NO_SYSTEM_FIELDS and/or
QUERY_GET_NO_TRANSLATED_SYSTEM_FIELDS for the queryFlags parameter
of VWQueue.createQuery() to avoid retrieving system fields and helper
data from the work items returned. Helper methods on elements are
not functional without translated system fields.
- Create indexes, and limit the number of indexes, to achieve more
efficient queries with less data transmitted. Indexes are to be unique.
- Use filters to get the ranges of elements for more efficient queries
with less data transmitted. Use filters for the following purposes:
- To limit the elements that are retrieved to a specified range
- To set a maximum number of objects to be retrieved for each fetch
from the Content Platform Engine server
(default is 50 items)
.
Guidelines for Generating Pattern-Matched
Lists of User and Group Names with LDAP Data Security
To
optimize lists of user and group names in systems with LDAP Data Security,
the following guidelines are to be observed:
The result list
from the
VWSession methods
findGroups() and
findUsers() is
determined by four input arguments: search pattern, search type, sort
type, and buffer size. These methods can be invoked directly through
a custom application or indirectly through a FileNet® Participant Selection Dialog. This
dialog can be accessed through the following applications:
- Process Configuration Console
- Process Tracker
- Process Administrator
- Process Designer
- Sample Java™ Step Processor
client utilities
Whether one of these methods is invoked directly or indirectly,
the output list normally has the following characteristics:
- Contains names that match the search pattern according to the
rules of the search type.
- Is ordered according to the sort order specified by sort type.
- Is transported from the Content Platform Engine (internally)
in chunks that contain the number of records that is specified by
the buffer size argument.
The name lists produced by VWSession.findGroups() or VWSession.findUsers() have
limitations that depend on the particular combinations of input arguments,
as follows:
- When the search type is NONE, the following special considerations
apply to the other input values:
- Search pattern is ignored, and a NULL search pattern is allowable.
- The sort type is ignored, and a list that is sorted in ascending
order is always returned.
- For the Sun Java System
Directory Server, set the Content Platform Engine Administrator
user account size limit to -1 (no limit). Doing so eliminates possible
side effects of a security server buffer size limitation.
- When the search type is an input option other than NONE, special
considerations apply to the other input value options and the resulting
list of names. These special considerations depend on whether the
sort type is NONE or one of the other possible options (such as ASCENDING
or DESCENDING).
- When the sort type is NONE:
- The buffer size setting is the maximum number of records that
can be returned by the method call.
- The actual number of records that are returned is the lesser of
the input buffer size and the directory server size limit.
- When the sort type is an option other than NONE:
- The buffer size setting is the maximum number of records that
can be returned by the method call.
- A non-null search pattern is required, except when the search
type is NONE. This exception is because the NONE search type ignores
the search pattern.
- The security database must contain an index for sorting. If the
appropriate security database index does not exist, the Content Platform Engine logs and displays an
error message similar to the following example: VWServer Exception:
Unavailable critical extension. LDAP err = 0x0000000c