SE_LOG: when AAALR(6.186927) is greater than 1.000000, we suggest using new row applicator to improve time and mem effeciency.

[Siva_Sankar]

Warning

SE_LOG: when AAALR(6.186927) is greater than 1.000000, we suggest using new row applicator to improve time and mem effeciency.

What does it mean ? what is this new row applicator ? What is AAALR?

I already referred the thread What is New Row Applicator  ? but no luck, I have lesser distinct values in dashboard.

Can any one come across this issue or share your experience?

[#2]

Hi,

I've had this previously and response regarding this message from Qlik was

AAALR refers to the average length of the aggregation array. For some customers who have large data sets, poor response times ,and/or complex calculations this warning will present in their logs. The general fix for this is to add this entry to the [Settings 7] portion of the Settings.ini for QlikView Server on all nodes:
DisableNewRowApplicator=0
This will switch to a new aggregation array which improves performance.

hope that helps

Joe

[Emmanuelle__Bustos]

And this really solved the issue after the Fix?

[mongolu]

Hello Joe Simmons.

Do you have more details about this?

Did you try it? What was the result of it?

I saw this entry in EventLog and I wondered which it could be the meaning.

I don't have problems with application, just this.

And it's very tempting to try it, if the outcome would be an increase in performance. But without any other info, it's only tempting.

[#5]

Hi,

Yes we did put this setting change in, which did resolve the log messages. I can't say I noticed much of a performance change, though the client had very large boxes, so harder to spot perhaps.

I don't really have any further info beyond that though, your best bet is to raise this is Qlik support and just confirm what I have said and ask for more info too

hope that helps

Joe

[arieidel]

Hello JoeSimmons,

Have you noticed any improvement since this configuration has being set?

We have found the same message in our log and Qlik told us to do exactly the same so any experience or feedback from other users would be helpful.

Thanks,

Ariel

[#7]

Hi Ariel,

like I said previously, I don't have any definitive stats on the improvement of this change I'll be honest. All I can say is this had no adverse effect and due to the size of the boxes the client had the improvement would be difficult to quantify without more analysis, but even a small improvement is better than none for such a small change.

Sorry I can't be of more help

Thanks

Joe

[Anonymous]

AAALR = average aggregation array length rate

You won't find a lot of detail on this around as I believe providing it would be getting too close to revealing some of the secrets that power the Qlik products. I might be wrong and someone from support or product development will reveal more.

Regardless, don't panic, this isn't an error as such, rather a hint that a particular visualisation associated with a field could perhaps be put together better. Consider conceptually what the Qlik engine is doing when we make selections, based on the dimensions a series of calculations are performed to produce aggregations using the defined expression(s). At some point in the process there will be an array of aggregated values, in fact the result set is likely to be an array of arrays of aggregations. So, if the average length of those aggregation arrays is very long that is possibly going to have an impact on performance.

[reanfadyl]

Hi,

I went through the trouble of 'fixing' one of these warnings by identifying the chart Expression that was causing the problem. 

To be honest I am not sure it was worth the effort in terms of performance, though it is nice not to see the Warning coming up anymore.

Analysis

An AAALR warning  was coming up frequently on the QlikView server logs.

The problem (I think) seems to have been caused by a nested IF expression which ‘forced’ Qlik to make an outer join between my FACT and SPECIALTIES  tables in its internal aggregation array prior to calculation.

See Rods earlier post , and HIC 's The Calculation Engine - "However, be aware that QlikView will create all combinations of the two fields before summing, and that this could in odd cases cause duplication of records."

Anyway after changing my expression to use to the %_SPECIALTIES key directly the warning seems to have gone away.  I imagine the same thing could be achieved better with Set Analysis, but I haven't had a chance to work on the statement yet.

My Data Model

Star Schema - Single Fact Table with a 'Perfect Key' join to my SPECIALITIES dimension table.

My AAALR  Errors:

2016-04-04 16:46:15        2016-04-05 08:54:05        4        700    Information          SE_LOG: aggregation on 'Fact'(%_SPECIALTIES), dstCardinal(33) and AAALR(2.434683).

2016-04-04 16:46:15        2016-04-05 08:54:05        2        500    Warning          SE_LOG: when AAALR(2.434683) is greater than 1.000000, we suggest using new row applicator to improve time and mem effeciency.

My ‘Problematic’ Expression

If([SPECT Specialty] = 'Endoscopy', Sum({$<FactSource = {'BILL_INFO'} }>}[Price 2])/9.99,

If([SPECT Specialty] = 'Cardiology', Sum({$<FactSource = {'BILL_INFO'} }>}[Price 2])/9.99,

Sum({$<FactSource = {'BILL_INFO'} }>}[Price 2])/9.99))

My ‘Fix’ Expression - though I am sure there is a smarter way using P() or something… I am open to suggestions

If([%_SPECIALTIES] = 1, Sum({$<FactSource = {'BILL_INFO'} }>}[Price 2])/9.99,

If([%_SPECIALTIES] = 2, Sum({$<FactSource = {'BILL_INFO'} }>}[Price 2])/9.50,

Sum({$<FactSource = {'BILL_INFO'} }>}[Price 2])/9.12))

[Anonymous]

Thanks Rean, that's really useful detail for everyone.