- 02 May 2022
- 3 Minutes to read
- Contributors
- Print
- DarkLight
Setting Up MetaManager Performance Options
- Updated on 02 May 2022
- 3 Minutes to read
- Contributors
- Print
- DarkLight
Performance Options
When you need to establish or modify the application's performance options, you must:
▸ 1. From the Tools menu, select Options.
▸ 2. Select the Performance tab. These performance settings are used to control how data is handled during conversations with the gateway. To limit the impact on the server or workstation running MetaManager™, you can set the various MetaManager™ application performance options.
NOTE: The performance options set within MetaManager™ are not directly related to your IBM Cognos server performance. They are options set and used by MetaManager™ on the machine running MetaManager™.
» Communication Threads
When modules perform their work, concurrent threads can often be used to process multiple actions at the same time. While increasing the thread count can speed up MetaManager™, it also puts more of a load on the machine running MetaManager™ and the IBM Cognos server. Therefore, we recommend four (4) threads as the default setting. Trial and error can be used to determine if there is a more effective thread count to use in your environment.
» MetaManager™ Timeout
This setting represents the amount of time in seconds that an HTTP request will stay open before closing due to inactivity. The recommended setting is 300 seconds (5 minutes). Trial and error can be used to determine if there is a more effective timeout value to use in your environment.
NOTE: Certain modules require more time to gather the requests necessary to complete (i.e. Content Store Documenter). The module requiring the most amount of time to gather information needed (thus requiring the HTTP request to remain open) is the one that should be used when considering modifying this setting.
» Portal Tree Objects Default Display Count
For scalability and performance, the MetaManager™ portal tree and search trees can be configured to retrieve and display a specified number of objects at a time. If there are more objects in any given lineage to be displayed, a "More..." node will be shown at the bottom of the list. The user can select "More..." to retrieve the next batch of results.
MetaManager™ should never lock up while loading even very large lists of objects. As large lists are often difficult to browse in a meaningful way, MetaManager™ can be configured to load a reasonable sampling from the list.
The default setting is to display 25 objects at a time. Each MetaManager™ user can change this number based on their preference.
NOTE: The powerful search capability in each module enables users to easily find the content they are looking for and can be very beneficial in instances where a large volume of content exists.
» Maximum Content Query Objects
While the MetaManager™ portal tree and search tree use the More... limit for scalability and performance, the grid area of a module must use the maximum query objects limit. When a module processes a list of objects, all of the objects must be loaded. If a request is made to the server to load a list of objects, and producing that list exceeds the server or client timeouts, then the request will fail. Instead of requesting the entire list, MetaManager™ breaks up the request into smaller chunks.
For example, if 10,000 objects exist in any given request, all 10,000 will eventually be loaded into MetaManager™ if desired. However, MetaManager™ may have made 100 calls to the server to produce the list.
The recommended setting is 300. A higher batch count will:
▸ Produce fewer calls to the server
▸ Increase MetaManager™ performance
▸ Increase the risk of a timeout
▸ Decrease MetaManager€™s™ responsiveness (i.e. to a cancel request)
Trial and error can be used to determine if there is a more effective maximum content query value to use in your environment.
Allowing the use of temp files to conserve memory Running certain processes on a large number of items can consume large amounts of memory on the client. Allowing the use of temp files to conserve memory allows MetaManager™ to write some of that information to disk to save memory. The files on disk are cleaned up automatically when the application is closed.
NOTE: Selecting the option to use temporary files will reduce the memory footprint, but will also add substantial overhead to the process; this can cause a process to take much longer. Depending on resources, disk speed and file size some processes could potentially take several times longer than without it.
» Enable GZIP
This option is selected by default and enables GZIP for compression of HTML and Javascript files so they can be sent over the network quicker.
Next Article: Introduction to the MetaManager Bundles