Performance recommendations for IBM CMIS for Content Manager Version 1.0

Content

Item Types

• The item type classification resource is the recommended classification to use with IBM CMIS for Content Manager. The item type classification resource represents optimized single-part documents. Item type definitions with the item type classification document, which represent multiple-part documents, are supported but they do not perform as well as resource item type documents since they are not optimized for a single binary content. Document-classified item type documents operate in a compatibility mode and can experience some behavior limitations. Item type definitions with the classification item or standard, which represent no-content documents, are supported as zero-byte documents with full metadata support and cannot be created or updated with more than zero-length binary content.

• To display the correct file size and MIME type in all listings, use the resource item type types classification to retrieve the information efficiently. The file size and the MIME type are not always displayed accurately in all cases for compound document model item types classification for best performance, unless you enable the optional configuration setting to calculate file size at a cost to performance. Use document types that are classified with the item type classification resource, which means optimized single-part documents. Resource document types combine the document and single part into a single entity, and the part metadata is not retrieved separately. Therefore, the file size and MIME type are easily retrieved with little or no performance impact and their values are displayed during routine operations such as browsing.
  
• When browsing folders, you might see file sizes and MIME types for some multiple-part classified document types. This occurs when the document types are not CMIS-optimized, and therefore they do not contain optional extended metadata for the standardized name attribute. These document types operate in a compatibility mode and can incur performance costs to perform a best-effort mapping to the best possible existing attribute, which is a native field stored on the parts. During browsing, parts retrieval is optimized across multiple documents and is retrieved because browsing functionality does not work well without the best possible file name. This decreases performance. However, if you retrieve the document and request only metadata or properties, the file name is not retrieved. Instead, a name is mapped to the next best value from the metadata values that are retrieved. Therefore the filename might not be correctly displayed. To resolve these issues, follow the best practice of using only the resource classified document type.

See Item type classifications for more information.




• If you add the optional metadata extensions to make any item type optimized for CMIS, you must use the DocumentTypeEnable tool to add the extensions and the database indexes required for performance. The DocumentTypeEnable tool is the only tool that can add the necessary database indexes to perform and scale correctly.
  

• To get optimal behavior, you must use a document type that is optimized for IBM CMIS, such as CmisDocument as the default document type for the library.

See Document types optimized for CMIS for more information.

• If string values for a particular property are always the same length, use Char, which is a fixed-length string attribute, instead of Varchar, which is a variable-length string attribute. Char performs much faster than Varchar. However, Char automatically pads white space for any string submitted that is smaller than the specified length. This makes fixed length strings harder to query by the exact string if any values are smaller than the full size. For the most flexibility, Varchar is a good choice if you have strings that greatly vary in length.
  
• Choose reasonable maximum lengths for your string attribute definitions, because the metadata of an item type is limited to 32K in the database. The actual metadata size limit depends on the table space size that is used when creating the repository database. Unicode strings can consume multiple bytes per character and can vary depending on actual characters in each string. Drafts of items with metadata that is less than approximately 25K perform much faster than drafts with more metadata. Draft instances with more metadata require expensive overflow storage that does not perform fast or scale for large numbers of such drafts.
  
• Regardless of actual capacity, applications and users should use metadata values with a total size of 100 KB or less for better performance, or 32 KB for best performance. You might configure for reduced maximum capacity on DB2, but this practice is not common. You might need to review the best balance of metadata size capacity and performance on DB2. The metadata size capacity is based on the amount of bytes that are used per property value. For example, string values can consume between one and four bytes per character depending on the code page and actual characters used. The larger the property value, the more bytes it uses for metadata capacity. Features such as drafts and global text search indexing might impose a reduced metadata capacity due to metadata formatting and capacity used by these features.
  

See Cannot save document for more information.

• The use of BLOB attributes are not recommended as a best practice. The existence of document types with BLOB attributes degrades the performance and scalability because the document types with BLOB attributes are not optimized for multi-item data retrieval.

See Property type mapping reference for more information.

• The getDocumentOverridesDraftFoundByID parameter controls corrections for document-scoped operations when a draft or private working copy ID or fast path is submitted. Enabling this setting (default) is recommended. Disabling this setting will ensure best performance and scaling but will require applications to follow best practices to distinguish IDs and fast paths, or the applications might not behave perfectly. You can leave this enabled in most cases without noticeable reduction in performance. Disabling this setting forces application compliance or forces the user to work around application limitations. This setting allows you to automatically work around without drawing attention to the application.

See getDocumentOverridesDraftFoundByID documentation for more information.

Important: You can find more performance-related information with the configuration settings because the configuration setting parameters help balance behavior and performance in your environment. The following configuration settings affects the balance of behavior and overall performance:

• passwordValidationInterval
• enablePrivateDrafts
• enablePrivateReservations
• fastFolderAccessPaths
• fastFolderTreeCopyAccessPaths
• fastDocumentAccessPaths
• findDocumentWithoutFastAccessPath
• findFolderWithoutFastAccessPath
• findWithoutFastAccessPath_Algorithm
• findWithoutFastAccessPath_DocTypes
• findWithoutFastAccessPath_MaxLevelsPerQuery
• findWithoutFastAccessPath_SeparateWildcardStep
• findWithoutFastAccessPath_StepTimeout_s
• findWithoutFastAccessPath_UnscopedAssumesFolder
• listFileSizeForCompoundDocumentClassification
• maxChildrenListedPerCall
• revisedPathLookupCacheCapacity (maybe, not sure)
• timeoutFindItem_s
• timeoutGeneralQuery_s
• timeoutListChildren_s