Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi guys,
It's just take a few seconds to reload qvw when I executed in desktop. However, When I deployed it to qmc it will take 2 hours to finish the reload process.
I also check the task log. seem the task always stuck after the "start saving document".
did u know how to fix it?
Hi @marcus_sommer , I already found the root cause. I'd like to share it in here.
I checked the QVW file configuration. It applied email alert feature. However, the email STMP not set in the server. So, the workflow was blocked over 2 hours to trace email server address. Obviously, the session will fail after the timeout limitations.
thanks for your time.
The workload on the machines might be quite different. Further there may various settings in place which could add the task in a queue and waiting until other tasks have finished and/or the workload of CPU + RAM is below certain thresholds.
Also the used storage/network might be different in some way and causing any delaying.
Further take a look if there is also any distribution added to the task.
As @marcus_sommer said, this does sound like a recourse issue. Since there is a lot of time spent in saving the document, I would look into storage and network latency also.
Hi @chenpeng,
Marcus and Maria make great points. Something that may help you ensure that your Publisher/QlikView Distribution Service is working as efficiently as possible is the Scaling QlikView Publisher whitepaper. The Qlik Support article QlikView and its backend file system may also help.
Best Regards
Thanks for your reply. there is a distribution in the task. Besides the CPU + Memory usage is very low in the task running period. Seem the situation just appeared in this one dashboard...
Yes, It's so wired. Because only this one dashboard waste so much time to save document. Further the dashboard also not huge ( Just 5mb). So I just guess anything blocked the saving process. But I don't know how to trace it ...
Detecting the real cause could be quite hard. To do this you could carefully monitor the various log-files from QlikView + Windows - directly or with the help of various governance-applications respectively with own QlikView applications. If nothing could be found respectively isn't specific enough you may try to trace the live-behaviour with tools like WireShark and/or the ProcessMonitor.
If you or any colleagues have these tools already in use and are experienced with them it shouldn't be very difficult. If not I suggest to consider the above suggestion rather as a worst case measurement and think you should rather try at first any kind of exclusion approach.
For this you could duplicate the application with a new name which would remove all meta data/files and then creating a new task without any distribution. Also removing all respectively some of the access rights maybe by moving the application to another folder could exclude access-issues.
Another step might be to recreate the application which means a complete new application with only a copy & paste of the script - nothing else. This would exclude that any UI stuff like macros/actions/variables and so on have an impact and further that the application is corrupt in some way or that there are some kind of incompatibilities between the release which has created this app and the current server-release. In this regard take also a look that the releases of the desktop client and the server-services are identically.
Hi @marcus_sommer , I already found the root cause. I'd like to share it in here.
I checked the QVW file configuration. It applied email alert feature. However, the email STMP not set in the server. So, the workflow was blocked over 2 hours to trace email server address. Obviously, the session will fail after the timeout limitations.
thanks for your time.