What settings should I be changing in the Web Viewer Administration Tool's File->Preferences? Are there any recommendations for settings under those tabs and what are the potential ramifications of those changes?

Products

• Output Management Document Viewer
• Output Management Web Viewer

Issue/Introduction

Description:

Let's discuss each setting/parameter as they occur under each tab/panel.

Solution:

<Please see attached file for image>

General Tab

Preferences

Reports per request:

Set this to whatever number of reports you want to be displayed on the Reports List at one time (Reports 1 ? n of nnn). The user would need to click on the 'go to next' arrow for the next group of "n" reports. This setting should not have any significant impact on server or user performance. The recommendation would be whatever fits on a user browser screen and can be viewed all at once (without needing to scroll down).

Maximum number of reports:

Set to the maximum number of reports you want to receive from the Repository with the initial Filter Settings. You can still do further filtering after the initial Reports list is displayed. This setting can have significant impact on performance if the number is not limited to the point where it impacts business requirements while keeping the number under 10,000. If possible, setting the parameter to 5000 or less is recommended.

Number of Pages per Request:

Set to the number of pages to be displayed for a user browsing text report data in the initial and subsequent display caches. This setting can have minor impact on user or server performance. The actual number of pages being delivered for display are 15 at one time. It is recommendation that this parameter be set to a number that is a multiple of 15 but not more than 45.

Maximum number of Value entries:

Set to the number of Cross Report and Logical View index values to be retrieved and displayed for the filtering provided (Limited), or for no maximum (Unlimited). Using a "Limited" number is very highly recommended! If an unfiltered request returns 10,000 or more values, it can have a serious impact on user and Server performance. That includes timing out before completion and spiking CPU levels on both the mainframe and PC Server sides. Setting this parameter to 500 or less (with 100 being the most efficient) is recommended. The reasoning for this recommendation is that most users will not page down through more than 100 indexes looking for a value but will use filtering to narrow down the search.

Thread Pool

The thread pool numbers represent the worker threads used by Web Viewer for each individual request which normally will be for a very brief (less than one second to 2 seconds) time periods - after which the same threads can be used for other active users on the system. There can be situations where a few threads can be waiting for a long request, tying them up for longer.

Initial Thread Count:

Set to the initial number of worker threads for user requests in Web Viewer depending on the average number of users working concurrently during the day. This can have minor impact only as the important point is that the overall Thread Pool settings are sufficient to meet business requirements. Set this parameter to 16 unless very large numbers of users are going to be making requests concurrently.

Number of Threads to Grow by:

Set to the number of threads to be added at the time that the initial or current threads are all active with user requests. Because the number of threads also declines as requests release their threads, this can have only a minor impact as the important point is that the overall Thread Pool settings are sufficient to meet business requirements. The recommended setting is a number that is a multiple of the initial Thread Count which reflects the expected usage.

Maximum number of threads:

Set to the maximum number of worker threads that Windows can assign to the Web Server based on the maximum usage required for meeting business requirements throughout the business cycle. This number will have the effect of stopping new requests if all threads are busy until one frees up. It is very unusual for that time period to be more than a second or 2. The recommended setting is a number, sufficiently high based on expected usage, which is also a multiple of the other thread settings.

Email Type

This is typically set to Client based MAPI and there is no impact on either user or server performance.

<Please see attached file for image>

Timeouts Tab

Logoff user after <nnn> minutes of inactivity:

Set to the amount of time before a logged-in, Web Viewer user who has been inactive should be considered 'away' and forced out so as to not be using any Web Viewer resources until logging on again. This setting is based on business requirements considering the Server resources made available to the application and number of users needing access. This can have some impact on the cooperative process overall, but not normally the Web Viewer users or Server. The recommended setting is from 20 to 30 minutes.

Remote response time <nnn> seconds:

Set to the maximum number of seconds that a remote data request should be allowed to wait for a response before timing out the request and allowing the user to make a different request. This is based on what the expected maximum response should be depending on the types of remote requests and where they reside within business requirements. If the data resides on archived tapes that can be recalled with an application such as EAS, this time should take that possible delay into consideration. This can have an impact on the user and Server if the request is so large that it results in mainframe/PC resources being used for a long time. The recommended setting is 600 if you expect some long requests in order to meet business requirements.

Delete personal user account after <nnn> days since last log-in:

Set this to 0 (zero) to allow personal user accounts to exist indefinitely unless administered separately in the View->Personal User Accounts dialog. If there is a business requirement to have personal user accounts expire after some number of days of inactivity, then set this parameter to that number of days. This setting will have no impact on either user or Server performance.

<Please see attached file for image>

Statistics Tab

This tab is informational only and has no bearing on user or Server performance. It can show relevant information to the load on the server from which other preference settings can be based.

<Please see attached file for image>

Security Definition Tab

Login Security:

This setting will not directly impact user or Server performance and its choices and meaning are well documented in Chapter 4 of the OM Web Viewer Administrator Guide. Please refer to that document for further information.

User Session Validation:

Use both, either, or neither of Session Cookie or IP Address to validate that a user is authenticated. If the selected type(s) are found to be different, the user will be removed from the Web Server with an appropriate error message. The recommended setting is for Session Cookie which eliminates any problems if IP Addresses are not static.

<Please see attached file for image>

Printing Defaults Tab

These settings are dependent on business requirements and will not impact user or Server Performance.

<Please see attached file for image>

Auditing Tab

This allows tracking of user requests for various functions of the Web Viewer and includes some response time information for certain requests as well. Selecting one or more of the User Action Auditing criteria causes a monthly spreadsheet (.CSV) file to be created and populated. This can have a some impact on CPU and storage resources if all items are checked and there is high usage. Auditing can be useful in determining how users utilize the product which can lead you to better decide how other Preference parameters should be set. CA Support may request that some or all of these be turned on temporarily for assistance in issue resolution.

<Please see attached file for image>

Global User Actions Tab

Limits:

Format for eMailing Text Reports:

Set these limits per business requirements. They can affect user and Server performance significantly if users are allowed to download for emailing, saving, printing, and/or exporting text reports that are millions of pages. Recommended settings are for meeting business requirements but limiting these options to whatever degree is possible.

Format for Saving Text Reports:

This can be set to convert text reports to PDF format for emailing and saving and has very minor impact to the Web Viewer.

Environment

Release:
Component: DVWEB