Skip to main content
Announcements
Qlik Connect 2024! Seize endless possibilities! LEARN MORE
cancel
Showing results for 
Search instead for 
Did you mean: 
chenpeng
Contributor II
Contributor II

QMC task reload execution time longer than local reload

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". 

chenpeng_1-1712129702129.png

did u know how to fix it? 

 

Labels (3)
1 Solution

Accepted Solutions
chenpeng
Contributor II
Contributor II
Author

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.

 

View solution in original post

7 Replies
marcus_sommer

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.

Maria_Halley
Support
Support

@marcus_sommer 

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. 

 

Chip_Matejowsky
Support
Support

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 

Principal Technical Support Engineer with Qlik Support
Help users find answers! Don't forget to mark a solution that worked for you!
chenpeng
Contributor II
Contributor II
Author

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...

chenpeng
Contributor II
Contributor II
Author

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 ...       

marcus_sommer

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.

chenpeng
Contributor II
Contributor II
Author

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.