dcsimg

What are the optimal settings for table sizes?

Products

Webtrends Analytics 8.x
Webtrends Analytics 9.x

Cause

While the default settings are intended to ensure successful analysis for the average installation, web traffic volume and business needs may dictate report limits be increased for a certain report occurring in all profiles and/or reports on specific profiles.

Resolution

Before making changes to a table, assess the report’s current capacity. Edit the profile, and under Analysis > Table Sizes the report’s Analysis Status and Report Status (shown as a red ball) will be the first indicator whether or not one or both of the tables should be increased. If the Potential Memory Impact and the Current Memory Impact are equal or close in value this would suggest the volume of data entering the tables is being constrained by the limits currently imposed on the table. Also, verify the analysis and report counts equal the limit plus one for the first dimension and/or plus two for the second dimension.

Following this assessment, consider the memory impact relative to the available system resources, and in this respect the version of Webtrends used, the version of the operating system used and the amount of memory installed on the server(s) are factors. Webtrends Analytics versions 8.0 through 8.5a are 32-bit applications, thereby limiting the amount of memory that can be allocated to a single process. This limitation is also imposed on these versions running on 64-bit operating systems, that is to say, a 32-bit application installed on a 64-bit operating system will still be limited despite the capabilities of its host. The largest amount of memory that can be utilized for a single process on a system with 32-bit limitations will be just over two gigabytes, and the amount used will be evident in the memory impact information in the table settings as well as in the line which includes “max memory usage” in the profile’s status log. Additionally, performance on 32-bit installations may be further affected when running multiple concurrent tasks on a single analysis engine, placing these tasks in competition with each other and either causing failure or delaying the completion of analysis.

Note: Webtrends Analytics 8.7d and later versions are 64-bit applications which include some 32-bit modules and are therefore installed in the Program Files (x86) folder by default. The presence of the application in this location does not imply that the above-mentioned memory limitations are an issue, but rather, that the application as a whole is not natively 64-bit compliant and therefore cannot be installed in the Program Files folder on a 64-bit operating system.

Assuming resources are available, edit the table sizes where applicable. Global table limits can be configured in the user interface by navigating to Administration > Web Analysis > Options > Table Sizes, then edit the report. For individual profiles, edit the profile and navigate to Analysis > Table Sizes, then edit the report. Changes made to global table limits will apply to every occurrence of that report within the installation, and the performance impact will vary from profile to profile. Changes made to the report on a profile level override the global configuration for the report on that particular profile.

The table modification details for one-dimensional reports are as follows:

Analysis Count (current)
Number of elements – This value is only visible when editing table limits on a profile level and shows the number of elements currently in the analysis table.

Analysis Limit
Number of elements – The limit for analysis elements in the first dimension.

Report Limit
Number of elements – The limit for report elements in the first dimension.

Note: The report limit must not exceed 20% of the analysis limit due to the increased memory requirements for generating report data for display in the user interface. If the level to which the report limit must be increased exceeds 20% of the analysis limit, increase the analysis limit as well to maintain the ratio between the two.

When increasing the table limits for a report for which the analysis count is not at its limit, use the analysis count as a point of reference by which to make the changes. For example, a report with an analysis limit of 10,000 and a report limit of 2,000 has an analysis count of 7,000 and a report count of 2,001, indicating that the additional 5,000 entries are unable to be displayed due to table limitations. If the goal is to include all of the data shown in the analysis table in the report table maintain the 5:1 analysis-report constraint between the tables by increasing the analysis table to the point where the current analysis count is less than 20% of the total analysis limit (and this will be the new report limit). Increasing the analysis limit to 40,000 and the report limit to 8,000 will ensure the report count includes all 7,000 elements currently in the analysis table, with an additional 1,000 elements available for future growth. Additional entries will populate the report table after the next analysis.

When increasing the table limits for a report where both the analysis count and report count are at their limits, the optimal degree by which limits may be increased will not be clear based on the table limits alone. In this situation it may be helpful to compare the volume of data in a similar report that has larger table limits. Without a point of reference, it is recommended the table limits be increased conservatively in incremental steps, then analyzed and monitored for performance until the optimal limit has been reached. The definition of optimal limit would be one in which analysis completes successfully, consistently, and without significant impact on system resources or other tasks. Refer to the “max memory usage” value in the profile’s status log to determine resource utilization. If, after increasing the table limits, analysis fails, it is recommended table limits be reduced to their former levels and an analysis attempted again to confirm whether or not the table limit increase was the cause.

The table modification details for two-dimensional reports are as follows:

1st Dimension:
Analysis Count (current)
Number of elements – This value is only visible when editing table limits on a profile level and shows the number of elements currently in the analysis table in the first dimension.

Analysis Limit
Number of elements – The limit for analysis elements in the first dimension.

Report Limit
Number of elements – The limit for report elements in the first dimension.

2nd Dimension:
Analysis Count (current)
Number of elements overall – This value is only visible when editing table limits on a profile level and shows the total number of elements shared between the second dimension’s analysis table and report table.

Analysis Limit
Number of elements overall – The maximum number of elements between the second dimension’s analysis table and report table.

Number of elements per 1st dimension value – The limit for analysis elements in the second dimension for each analysis element in the first dimension.

Report Limit
Number of elements – The limit for report elements in the second dimension.

The second dimension contains a pool of elements shared by the 2D analysis and 2D report tables. It is recommended that the size of this pool be made equal to the product of the size of the 1D analysis table and the 2D analysis table in order to accommodate the scope of second-dimensional elements for each first-dimensional element. For example, a report with a 1D analysis limit of 1000 has a 2D analysis per 1D limit of 200, meaning for each of the 1000 entries in the first dimension, 200 elements are possible. The number of 2D overall elements required to fill the table will be 200,000. For the 2D report limit, observe the same 5:1 constraint between the analysis table and the report table mentioned above.