Optimizing Groove Forms Tool Performance
Summary: The Groove 2007 Forms Tool and the InfoPath Forms Tool are customizable and programmable general-purpose tools. Understanding the performance effect of design decisions allow you to make appropriate performance tradeoffs. (4 pages)
Josh Goldman, Microsoft Corporation
Applies to: Microsoft Office Groove 2007, Microsoft Office InfoPath 2007
The Microsoft Office Groove 2007 Forms Tool and the Microsoft Office InfoPath 2007 Forms Tool are customizable and programmable general-purpose tools. If you are developing a complex solution that handles many documents, you must understand the performance effect of your design decisions. In general, Groove 2007 Forms tools and InfoPath Forms tools have the similar performance tradeoffs.
Record Update Performance Issues
When a record is updated, the number of indexes included in the record that must also be updated has a direct effect on performance. The number of indexes associated with a record depends on Forms tool implementation details that most forms designers are not concerned with or are not aware of. However, because the number of indexes affects the performance of the tool, the next section describes the implementation details of Groove 2007 that add indexes to records.
The Forms tool implementation creates indexes in several situations, when the following conditions are true:
One index is created for each column that is sorted in a filtered view. If the same column is sorted in more than one filtered view, a separate index is created for each filtered view.
One index is created for each column that is sorted in any unfiltered view. The tool creates a single index for a sorted column even if it appears in more than one unfiltered view.
If the design specifies that a column can be sorted in both ascending and descending order, the tool creates two indexes for that column.
When a record is updated, the forms tool updates the following indexes for any field that has a changed value:
One index for each filtered view that includes the record and has the column sorted in a single order.
Two indexes for each filtered view that includes the record and has the column sorted in both ascending and descending order.
One index if the column is sorted in the same order in one or more unfiltered view.
Two indexes if the column is sorted in ascending order in one or more unfiltered views and is sorted in descending order in one or more unfiltered view.
Consider the following examples in which the Forms tool includes:
Five filtered views that sort the data in the ItemID column.
No unfiltered view that has sorted data in the ItemID column.
The tool creates the following indexes:
Five separate indexes, one for each filtered view
If a record is updated and the value of ItemID is changed, the tool updates the following indexes:
One index for each filter that includes the record. If all five filters include the record, five indexes are updated.
Forms tool includes:
Five unfiltered views that sort the JobTitle column.
Some of the unfiltered views have JobTitle sorted in ascending order and others have it sorted in descending sort order.
No filtered views.
The tool creates the following indexes:
Two indexes for the JobTitle column, one sorted in ascending order and one sorted in descending order.
If a record is updated and the value of JobTitle is changed, the tool updates the two indexes. If the JobTitle is sorted in the same order in all of the unfiltered views, the tool would create and update only one index.
If multiple, filtered views have both the same column sorted and have an overlapping set of records, the performance cost for updating records increases.
If a column is sorted in one or more than one unfiltered views, there is a performance cost; however, there is no additional cost in sorting the column in multiple unfiltered views.
Sorting a column in both ascending and descending order in the same filtered view doubles the performance cost of sorting by one order.
Sorting the column in ascending order in any unfiltered view and sorting it in descending order in any unfiltered view, doubles the performance cost of sorting it in only one order.
Filters and indexes provide significant benefits for users, in spite of the performance cost. Benefits include the following:
Filtered views make it easier for users to view a set of related records.
Filtered views may be required to hide some records from the user. For example, a tool may use keyword records to populate drop-down lists. It could be confusing to the user if these records appeared in views with other records.
Indexes allow the user sort a view.
Indexes make it possible to create lookups that use the values as keys in the indexed column.
Indexes can improve the performance of queries based on the values of an indexed column.
Indexing rich-text fields adds an additional performance cost.
Serialization Performance Issues
The process of converting a workspace or tool between its internal binary form and an XML form that can be sent to another Groove 2007 device is called “serialization” and “deserialization.” The following operations cause a workspace or tool to be serialized.
Sending a workspace to a new member who has accepted an invitation from you or to sending it to another device.
Saving a workspace as a template or archive.
Saving a Forms tool as a template.
The following operations cause a workspace or tool to be deserialized:
Accepting an invitation to a workspace.
Fetching a workspace on a new device.
Restoring a workspace from a template or archive.
Adding a Forms tool to a workspace using a tool template.
The time required to serialize a Groove 2007 Forms tool is proportional to the overall size of the data. Indexes are not included when a Forms tool is serialized but are built when a Forms tool is deserialized instead. Consequently, the number of indexes and the size of the indexes have no impact on tool serialization performance but have a significant impact on tool deserialization performance.
Form Access Performance Issues
Large scripts with many lines of code can effect performance when a workspace member accesses a Groove 2007 tool record. Performance is effect when members view records, change fields on a form, and update a record. You can improve the performance form access by following these recommendations:
Use field validation instead of validating field values with script code (when it is possible).
When appropriate, execute script code in the OnBlur, OnChange, OnClick, and OnFocus events instead of executing it in the OnBefore or OnAfter events for form initialization, submitting data, printing forms, and exiting forms.
In addition, you can improve form access performance by caching lookups.
InfoPath Forms Tools Performance Issues
Follow the same recommendations described previously to improve the InfoPath Forms tool performance and include an additional recommendation:
Only promote InfoPath fields that will be used as columns in Groove 2007 form views or that must be accessed as a column in the GrooveForms2 Web Service record operations.
Summary and Guidelines
The major design elements that effect performance are as follows:
Number of indexed columns.
Number of filtered views.
Total number of fields in all forms.
Total size of design information which includes number of fields, forms, and views, plus the size of images that are used in forms.
Number of lines of script code that execute when displaying or updating records.
The two that have the biggest impact on the efficiency of updating records are the number of indexed columns and the number of filtered views.
In addition to design issues, the performance of a specific instance of a forms tool depends on the following:
Total number of documents (records) stored in the tool.
The performance cost depends on the interaction of design elements and number of records stored in the tool. What represents acceptable performance depends on deployment requirements and user expectations. The following guidelines represent a large Forms tool that should perform at an acceptable level. If you are designing a Forms tool that will exceed one or more of these guidelines, make sure that you evaluate the tool performance before you deploy it in a production environment.
Evaluate Forms tool performance before you deploy a tool that exceeds any of the following:
Number of documents
Number of indexed columns
Number of fields across all forms
Number of filtered views
Total size of images that are used in design
There are also general Groove 2007 usage attributes that effect the performance of the Groove 2007 application and, therefore, effect Groove 2007 Forms tools running in the application. The effect of these attributes is beyond the scope of this document, but they should be included when you evaluate how a Forms tool might perform when it is deployed. These attributes include the following:
Frequency and size of updates to Groove 2007 data.
Number of members in workspaces.
Frequency of users updating Groove 2007 data when they are offline.
Known Performance Issues
In testing large Forms tools with 10,000 records, errors have occurred when exporting all records to an XML file. If you have a Forms tool with 10,000 records or more, I recommend that you minimize the number of times that you perform bulk operations on (in) the tool and exert control over the processing environment when you perform bulk operations. It is recommended that you perform these operations under the following conditions:
Ensure that workspace members are not updating records in the tool during the operation.
Perform the operation on a system with 4GB (or more) of memory and a fast processor.
Avoid performing any other CPU- or disk-intensive operations on the system until the bulk operation finishes.
Although this error occurs most frequently when exporting all records to an XML file, it is also possible that the error may occur when it performs the following operations:
Exporting the tool or the workspace to an archive.
Inviting a new member to the workspace.
Fetching the workspace to another device for an existing workspace member.
For more information about Microsoft Office Groove 2007 Forms, development and in general, be sure to take advantage of the following resources:
Groove 2007 Software Development Kit. Contains developer documentation for Groove 2007 Forms as well as WSDL, sample code and documentation for Groove 2007 Web Services.
Groove 2007 Developer Portal. Find information and links to resources about planning, developing, and deploying customized Groove-based solutions, templates, and tools.
MSDN magazine article: Help Teams Work Together With Web Services and Groove 2007. John C. Hancock, senior consultant at Microsoft, specializing in business intelligence and .NET development. Presents how to use Groove 2007 and Web services in real-world team collaboration scenarios.
The Groove Advisor. Provides links to important Groove resources from inside and outside Microsoft, and technical information for Developers and IT Professionals.
Chris Norman’s Blog. Chris Norman, a Development Lead for Microsoft Office Groove, has a series of great posts in his technically-focused blog.