Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hello,
We are facing CPU load problems on our access points due to massive concurrent exports from many users.
We tried to limitate excel export size using addition settings in the settings.ini files:
QvExportTimeLimitSec=480
QvExportMemoryLimitMB=90
This measure seemed effective.
But now, they found a way to by-pass those limitations exporting to csv files instead of xls.
We tried to add this additional setting :
RowLimitForCsvInsteadOfXls=150000
Unfortunately, it seems to be ineffective.
We have a QlikView 12.20 with clustered nodes (2 access points with a load balancer).
(QlikView November 2017 SR6)
Here below the content of settings.ini from both access points :
[Settings 7]
DisableNewRowApplicator=0
ServerLogFolder=\\XXXXXX\Application_Groupe\QLIKVIEW\Share_Prd\Logs
DocumentDirectory=\\XXXXXX\Application_Groupe\QLIKVIEW\Share_Prd\RootFolder
CanDynamicUpdate=1
NumberOfDocuments=-1
DocumentTimeout=28800
StandardReload=1
HF820UpdateCalNamedCals=0
UserCalList=C:\ProgramData\QlikTech\QlikViewServer\FUL.dat
DocumentList=C:\ProgramData\QlikTech\QlikViewServer\FDL.dat
NumberOfUserCals=756
NumberOfSessionCals=30
NumberOfUsageCals=300
NumberOfInfrequentNamedCals=0
NumberOfConcurrentInfrequentNamedCals=0
SessionCalsInUse=5
ClusterAlternateBuildNumber=0
ClusterName=QVS@Prod
UsageCalAvailable=300
WorkingSetSizeLoPct=80
ObjectTimeLimitSec=600
AllowServerSystemAccessMacros=1
MaxConcur=200
AllowSessionCollaboration=1
ExtensionsFolder=\\XXXXXX\Application_Groupe\QLIKVIEW\Share_Prd\ExtensionPath
ExportTempFolder=\\XXXXXX\Application_Groupe\QLIKVIEW\Share_Prd\TemporaryPath
ProhibitQvpxSessionRecovery=1
IdleSecondsBeforeClose=1800
LogFileMode=3
Verbosity=500
DocumentMounts="XXXXXX",1;
AuthenticationLevel=2
QvMetaAccessControl=1
AllowGeneralAccessToImagesThroughURL=0
MarginTop=20
QvThumbnailCacheUpdateInterval=60
AuditLogVerbosity=5
ConcurTimeoutSec=900
ServerLockLayout=1
NumberOfDocumentCals=-1
MaxCoreMask=-1
MaxCoreMaskHi=-1
xqn=-1
QvExportTimeLimitSec=480
QvExportMemoryLimitMB=90
RowLimitForCsvInsteadOfXls=150000
[Authentication]
Serial=XXXXXX
Organization=XXXXXX
Name=XXXXXX
Check=2253834781
LastLefUpdateAttemptDate=XXXXXX
efUpdateAttemptDate=XXXXXX
AuthenticationLevel=2
QvMetaAccessControl=1
AllowGeneralAccessToImagesThroughURL=0
MarginTop=20
QvThumbnailCacheUpdateInterval=60
AuditLogVerbosity=5
ConcurTimeoutSec=900
ServerLockLayout=1
NumberOfDocumentCals=-1
MaxCoreMask=-1
MaxCoreMaskHi=-1
reMaskHi=-1
eMaskHi=-1
MaskHi=-1
MaskHi=-1
Anyone here has an idea of what is going wrong limitations qlikview exports?
Thanks for your feedbacks.
I'm not really satisfied by those propositions but I guess there's nothing much we can do.
We still have more than 300 applications on our QlikView platform and our migration to Qlik Sense/Qlik Cloud is going on really slowly (5 to 10 application per year).
I will simply add more RAM and CPU to our access points (I wanted to avoid that)
Thanks again @marcus_sommer , @David_Friend
@ChrisCDCH yes I don't believe that setting will work to limit the size of a CSV, so are you still seeing CPU load issues with people now using CSV files? If so may need to either disable exporting entirely or increase resources...
An alternatively may be to restrict the UI objects to max. n columns/rows by not providing such large ones which couldn't be used as visual else are in general designed to be exported. This could mean to provide more specific/restricted ones and maybe also a few which are for exports/prints only.
Further helpful may be to provide dynamic objects to enable the user to choose the needed dimensions as well as limiting the number of them and the possibility to use too granular information vertically and horizontally at the same time (pivot only).
Also useful are visibility-conditions within the objects/dimensions/expression to disable them if there are too many possible values - this means something like:
count(distinct Dim1&Dim2&Dim3&Dim4) < 10000
Another way would be to output the most relevant/large subsets with a store-statement during the script-run.
Thanks for your feedbacks.
I'm not really satisfied by those propositions but I guess there's nothing much we can do.
We still have more than 300 applications on our QlikView platform and our migration to Qlik Sense/Qlik Cloud is going on really slowly (5 to 10 application per year).
I will simply add more RAM and CPU to our access points (I wanted to avoid that)
Thanks again @marcus_sommer , @David_Friend