Using Simulated Calculations to Estimate Calculation Time

You can simulate a calculation using SET MSG ONLY in a calculation script. A simulated calculation produces results that help you analyze the performance of a real calculation that is based on the same data and outline.

By running a simulated calculation with a command such as SET NOTICE HIGH, you can mark the relative amount of time each sparse dimension takes to complete. Then, by performing a real calculation on one or more dimensions, you can estimate how long the full calculation will take, because the time a simulated calculation takes to run is proportional to the time that the actual calculation takes to run.

For example, if the calculation starts at 9:50:00 AM, and the first notice is time-stamped at 09:50:10 AM and the second is time-stamped at 09:50:20 AM, you know that each part of the calculation took 10 seconds. If you then run a real calculation on only the first portion and note that it took 30 seconds to run, you know that the other portion also will take 30 seconds. If there were two messages total, then you would know that the real calculation will take approximately 60 seconds (20 / 10 * 30 = 60 seconds).

Use the following topics to learn how to perform a simulated calculation and how to use a simulated calculation to estimate calculation time.

Performing a Simulated Calculation

Before you can estimate calculation time, you must perform a simulated calculation on a data model that is based on your actual database.

To perform a simulated calculation:

Create a data model that uses all dimensions and all levels of detail about which you want information.
Load all data. This procedure calculates only data loaded in the database.
Create a calculation script with these entries:
```
SET MSG ONLY;
SET NOTICE HIGH;
CALC ALL;
```
If you are using dynamic calculations on dense dimensions, substitute the CALC ALL command with the specific dimensions that you need to calculate; for example, CALC DIM EAST.

Note:

If you try to validate the script, Essbase reports an error. Disregard the error.
Run the script.
Find the first sparse calculation message in the application log and note the time in the message.
Note the time for each subsequent message.
Calculate the dense dimensions of the model that are not being dynamically calculated:
```
CALC DIM (DENSE_DIM1, DENSE_DIM2, …);
```
Calculate the sparse dimensions of the model:
```
CALC DIM (SPARSEDIM1, SPARSEDIM2, …);
```
Project the intervals at which notices will occur, and then verify against sparse calculation results. You can then estimate calculation time.

Estimating Calculation Time

When you perform a simulated calculation, you record the results and use them to estimate actual calculation time.

To estimate total calculation time:

Note the times of all the intervals between application log messages generated by SET NOTICE HIGH.

See the table below.

Use the following calculation to estimate the time for a real calculation:

Total time required for simulated calculation, divided by the first simulated calculation notice interval, multiplied by the first real calculation time interval.

Table 35-1 Sample Intervals Between Log Messages

Calculation Notice Number	Simulated Calculation Time Interval (in seconds)	Sparse Dimension Calculation Interval (in seconds)
1	7	45
2	5
3	6
4	3
5	4
6	2
7	6
8	4
9	3
10	3
Total calculation time	43

In this example, 43 / 7 * 45 = 276.4 seconds, so the real calculation should take 276.4 seconds.

Factors Affecting Estimate Accuracy

The simulated calculation should return a time accurate to about 5%, excluding the following issues:

When these factors are present, this estimating technique more closely predicts calculation time when Essbase reaches 30%–40% of the simulated calculations (30%–40% of the messages generated by SET NOTICE HIGH).

Variations Due to a Chain of Influences

Using SET MSG ONLY as a calculation-time estimating technique should be validated against later CALCNOTICE intervals. The results of this estimating technique vary because of the following chain of influences:

Blocks differ in block density through the real consolidation process, therefore
The rate at which Essbase writes blocks to the disk differs, therefore
The rate at which blocks are processed in the cache differs, therefore
Actual results may differ from the predicted calculation time.

Variations Due to Outline Structure

Another factor that can make actual results diverge significantly from predicted is the outline structure. Calculations based on CALCNOTICE intervals assume evenly balanced processing time throughout the outline. Factors that can skew this balance include the following situations:

The model contains one or two sparse dimensions that are large in relation to the other sparse dimensions.
Larger dimensions have member configurations that result in multiple shared roll-ups.

Changing the Outline Based on Results

After you have estimated and analyzed a simulated calculation, you can make changes in the outline to improve performance.

From top to bottom in the outline, order sparse dimensions to create the fewest percentage increases in upper blocks:

Level 0 blocks following full model load: 100,000
Upper level blocks after consolidating only sparse dimension 1: 1,000,000
Upper level blocks after consolidating only sparse dimension 2: 3,000,000
Upper level blocks after consolidating only sparse dimension 3: 10,000,000
Upper level blocks after consolidating only sparse dimension 4: 300,000
Upper level blocks after consolidating only sparse dimension 5: 5,700,000

For example:

#4 (members = 10,000, 4 levels)
#1 (members = 500, 2 levels)
#2 (members = 100, 4 levels)
#5 (members = 10,000, 4 levels)
#3 (members = 20, flat)

Use the simulated calculation to generate the upper block count. These numbers may be accurate despite actual dimension sizes as noted next to the items above.

Caution:

The largest count of members is not always a good predictor.