AAALR is registered in the Qlik Sense logs

[Andre_Sostizzo]

The following messages will appear in the engine trace system logs:

QVGeneral: when AAALR(63.312046) is greater than 1.000000, we suggest using new row applicator to improve time and mem effeciency.
QVGeneral: - aggregating on 'RecruiterStats'(%DepartmentID) with Cardinal(87), for Object:  in Doc: ffe8a825-b52e-4ceb-aea2-30de0f2c3306

There has also been reports of end users seeing the message "Internal Engine error" when opening apps when the error above is present.

Also for QlikView see article SE_LOG: when AAALR(1072.471418) is greater than 1.000000, we suggest using new row applicator to imp...

Environment:

• Qlik Sense Enterprise on Windows, all versions

"AAALR" is a very low level concept deep in the engine. Generally speaking it means the average length of aggregation array. The longer this array is, the more memory and CPU power are to be used by the Engine to get aggregation results for every hypercube node.
 
When AAALR is greater than 1.0, normally the customer has a large data set and suffers slow responses and high memory usage in their app. In this case, Qlik Sense has a setting called DisableNewRowApplicator (default value is 1).
 
By setting this parameter to “0”, Qlik Sense will use a new algorithm which is optimized for large data set to do the aggregation, and will use much less memory and CPU power.

Changing this setting when they have AAALR warnings, making this change has resulted in drastic performance increases.

Possible setting values for DisableNewRowApplicator:

1 - Use Engine default
0 - Use new row applicator where Engine seems suitable
-1 - Force new row applicator all the time

Resolution:

• Stop all Qlik Sense services from the windows control panel / services
• Locate the “C:\ProgramData\Qlik\Sense\Engine\Settings.ini”
• Add this portion to the Engine Settings.ini file (press <enter> at the end of DisableNewRowApplicator=0 so the cursor rests on a blank line below it)

[Settings 7]
DisableNewRowApplicator=0
         <---- the cursor should be here when saving the file

• Restart all Qlik Sense services
• (If multinode) Complete the above steps on every node.

Related Content:

• How to start investigating a suspected Qlik Sense Performance issue  

[AdamBS]

Thanks for the article. On the Resolution you state the setting must be done on each node in a multi-node environment.  Is this 100% necessary?  If I have one node dedicated to the large Apps, would it hurt the system if only this node is set to force the New Applicator?

[Sonja_Bauernfeind]

Hello @AdamBS 

We generally advise settings to be identical across nodes. Especially when it comes to settings done in configuration files, rather than settings exposed per node in the management console.

All the best,
Sonja 

[al]

I guess this parameter in settings.ini is not persisting in case of version or patching level upgrade of the QS node, and therefore must be set again after a version upgrade - please confirm? Thanks.

[Sonja_Bauernfeind]

Hello @al 

While defaults can overwrite some .config file modifications, the engine settings.ini will retain all its values post-upgrade. Just tested it on a Nov 2023 to Feb 2024 upgrade.

All the best,
Sonja 

[henrikalmen]

Searching the forum I conclude that this NewRowApplicator algorithm has been around since at least 2015 in QlikView. Why is it still disabled per default in 2024 in Qlik Sense? Is there a downside / potential risk in setting the flag to 0 (or even -1)?

[Sonja_Bauernfeind]

Hello @henrikalmen 

Let me reach out internally to get you an answer for this. Though please note that I will be out of the office for two weeks and my response may be delayed because of this.

All the best,
Sonja 

[henrikalmen]

@Sonja_Bauernfeind I thought I'd try to bump this thread again and see if it's possible to find an answer to my question?

[Sonja_Bauernfeind]

Hello @henrikalmen 

I have returned to work; let me follow up on this.

All the best,
Sonja 

[Sonja_Bauernfeind]

Hello @henrikalmen 

Here is the answer: The reason for the NewRowApplicator is not enabled by default is down to how the engine default will function better for the majority of documents. While the NewRowApplicator will improve performance for specific (complex) documents, it does not benefit the majority of documents.

All the best,
Sonja 

[henrikalmen]

Thanks @Sonja_Bauernfeind for investigating this!

I do get the warning as described in the above post in our logs, but when enabling the NewRowApplicator in our development environment (same hardware and setup as our production environment) I can't really see an improvement in calculation time or anything like that, so perhaps I should just leave this parameter with its default value in the production environment.