Database Reference
In-Depth Information
4.7 CheCk your work
So far we have covered two of the three factors that impact performance the most:
dimensionality and cache settings. Before discussing calculations, it is important to
establish a testing strategy. There is some value in tuning processes individually. It cer-
tainly is faster, but is it realistic? Let me give you an example. Consider a test database
that has a block size of 32,832 and two large sparse dimensions: Customer (2,000 mem-
bers) and Products (20,000 members). The database has 615 k blocks and a block density
of 1.6%. The server is a 64-bit Linux with six processors.
Figure 4.9 shows the basic script used to aggregate the database.
It is pretty obvious that with the server capacity and database dimensionality, parallel
calculations should have a positive effect. The question is how much? The Essbase docu-
mentation says that the ratio of the task schedule to the empty task schedule provides a
good indication as to whether parallel calculations will have a positive influence. A ratio
greater than 50% means that parallelism may not help. task values can be obtained
from the log, shown in Figure 4.10, after a calculation is run.
This particular database has 54,000 tasks followed by 3,620, and so on. According to
the documentation, the benefit of parallelism decreases after the first few steps. Looking
at the empty tasks line, we see that 41,000 level-0 tasks are empty. If 41,000/54,000 is
greater than 50%, then parallelism may not provide any improvement. The value of 75%
is way above 50%. This should make for an interesting test case.
The test will be run for one, two, three, four, and six processors. CALCtASkDImS
will be set to two for all but the single processor because a setting of greater than two
made no difference in the task schedule or timed performance. The testing scenario is:
1. Clear the upper blocks prior to each test.
2. Stop the database prior to each test.
3. The calculation times were the logged times.
4. Each test was executed four times.
5. The longest and shortest times where thrown out. The remaining times were
averaged.
Figure 4.9
Essbase calc script to aggregate database.
Figure 4.10
Application log messages after a calculation.
