How to query why a report took so long to generate

[QlikMo]

I have a task that took 8 hours to run and I don't know why or how to find out the cause. It normally takes minutes.

On the qlikview server side it reloaded the document successfully and the chained task called the nprinting api to start the publish task. 

My question is how can I find out what was going on during those 8 hours? The report was sent successfully but a lot later than expected. 

The only log where I can see any reference to this is the nprinting_webengine.log file and all it shows 

'Windows login successful. The user with id x has been correctly identified as a Windows domain user with sid x'

The report is is just a simple table in an excel file, emailed to 7 users. There was no other reports schedules to go out around that time. IT report no server or network issues. 

nPrinting is at the latest version: May 2022 SR3

Thanks

[Lech_Miszkiewicz]

Hi, below are some of the questions I normally would ask

1. Is source app in QlikView or Qlik Sense
2. Is your environment fully supported (supported versions of all components on supported dedicated servers with all requirements met as per https://help.qlik.com !)
3. If QlikView - did you use LOCAL or QVP Connection
4. If QVP - did you configure QlikView settings to optimize QVP connection (this should be old legacy thing but I guess it is worth testing:https://community.qlik.com/t5/Official-Support-Articles/NPrinting-diminished-execution-time-with-QVP...
5. How big is your QlikView/Qlik Sense app?
6. Do you have enough resources on QlikView or Qlik Sense server
7. What is a spec of your QlikView or Qlik Sense server and what is a spec of NPrinting server. It is possible that you have negative ratio and NPrinting tries to run everything at the same time and stops the QlikView/Qlik Sense server
8. How many users in total you have in your NPrinting repository?
9. Are there any user filters?
10. Is there section access used?
11. Are you having any other filters applied on task or report or object
12. How is your task configured
13. Are those 7 users added individually or as a group
    1. Have you tried run this report to single user with variable list of emails of those 7 users?

Based on the image you pasted we can see that planning of that report execution seemed to take a lot of time. That is typical to complex user-filters-conditions scenarios with many users etc. It would be important to understand how this is setup and I guess it would require rather deep digging around app-user-filter-condition setup in your environment. 

thats it at the beginning i guess

cheers

Lech

[QlikMo]

Hi Lech,

Thanks for your quick reply. 

1. Source app is Qlikview 

2.  Yes all by the book. nPrinting May 2022 SR3 and Qlikview May 2022 SR1

3. Server connection QVP

4. Yes - settings in QV document match those on that post (push off, server performs refresh automatically)

5. Very small, the .QVW file is 305kb. The table that is attached to the report is 10 rows and 8 columns with small numeric values

6. Yes. We've recently moved away from NP16 and QV11.2 on a single server 2008 - 32gb ram. The apps are the roughly the same amount, maybe 2 extra reports on the new server 

7. Qlikview - server 2022 - 64gb memory - 8 cores

nPrinting - server 2022 - 48gb memory - 8 cores

8. No actual users of nPrinting apart from myself and the administrator account. We have about 350 users in the repository mainly used for external emailing of reports and using the user filter.

9. On this report - no. 

10. Section access never used in any report

11. On this report no conditions, filters or anything (on the report or the publish task). Quite literally taking the small table from Qlikview, attaching it as an excel and emailing  to 7 users. The excel template is just <<TB01>> and nothing more

12. I have shown the task screenshots below. I have set the nprinting admin as the user and then manually typed the emails into the email message. The QVW is reloaded in Qlikview and then on successful execution of that task the second task uses your brilliant api script include to execute the publish task. 

13. No group used. User email addresses manually typed. If I test the report now it will probably run fine as it normally does, hence why I want to find out what caused it to take so long. At that time there are no other nPrinting reports running, that was the last of the evening reports. I checked the task executions and that was the only long running task

Edit: it also stores the excel file to a local folder on the nprinting server

[Lech_Miszkiewicz · Accepted solution]

Hi @QlikMo 

thanks for a very robust answers - that helps.

Couple extra things to check:

• Is QlikView desktop version installed on NPrinitng machine exactly the same version as your QlikView server (Version + Release must be the same!)?
• Is your QVW supported?
  • no triggers...
  • no alternate states...
  • no always one selected value...
  • etc - long list is here and all points MUST be met: https://help.qlik.com/en-US/nprinting/May2022/Content/NPrinting/GettingStarted/HowCreateConnections/...

Otherwise...lets check few extra things in NPrinting:

• Do you have dedicated NPrinting App for this particular QVW connection?
  • If your connection to this qvw sits in the same NPrinitng App as other connections which have user filters NPrinting (I believe) it will have to go through all of those users and validate if they filters apply to your report or not (which usually takes the most of the time) - This is only based on my observation so please dont take it as a rule
  • If you dont have dedicated NPrinting APP - try to create one, then create connection within that new app and export-import report into it and recreate a task and test again. 

Given all the information provided there shouldn't be any issue. That really is a hard one to deal with. 

@Ruggero_Piccoli & @Frank_S - anything you can add guys?

[Frank_S · Accepted solution]

@Lech_Miszkiewicz 

You've got it fully covered!

Those unsupported items are pesky to say the least. There is a possibility that one or more have snuck into the QVW. If so, then they need to be removed as per:

• Unsupported QlikView Document item... - Qlik Community - 1714896

Another possibility rings true due to this point

• Yes. We've recently moved away from NP16 and QV11.2 on a single server 2008 - 32gb ram. The apps are the roughly the same amount, maybe 2 extra reports on the new server 

This tells me that there is a strong possibility that you are using the NP service user account to run the old NP 16 server, the new NP May 2022 server and the QlikView server. This was common practice with a lot of NP 16 customers.

However sharing the service account between these is also NOT supported and will get you into the very trouble that you are experiencing.

So to resolve this:

• Make sure that your NPrinting 16 server is disabled entirely. (check the service panel to force it to a disabled status as it 'could' still be running.
• Create a new, dedicated NP service account for the NPrinting server exclusively.
  • Dedicated NPrinting Server & Engine Service Accoun... - Qlik Community - 1716056

So in summary it is one or a combination of the following (if you have thoroughly covered @Lech_Miszkiewicz 's points.

NP 16 and Modern NPrinting are actually not supported on the same server (in case you did that. I am hoping that you installed NP May 2022 on a windows 2012 or higher supported OS) 

• https://community.qlik.com/t5/Official-Support-Articles/NPrinting-16-to-NPrinting-19-Migration-Playb...
  • NPrinting 16 (32 bit) and NPrinting 19+ (64 bit) and higher versions must not be installed on the same server concurrently.

Unsupported Items in the QVW

• These usually get exposed when changing environments or upgrading/migrating as has been done here recently.

Shared NPrinting service account in use that gets locked up when QlikView or another NPrinting environment is using the account to run service based operations. The delay in processing could very well be this alone as well but you really need to check each point above thoroughly in case this is a multi-level issue.

Hopefully it is the above because it is pretty straightforward to address these points..

Kind regards.

ps: 48 GB ram is a bit low but if you're QVWs are small and don't use up much room 'in memory', it should be OK. If you have large QVWs however, this may cause your server to also freeze up temporarily until memory clears up organically over the 8 hour period. In that case, keep an eye one your memory utilization as well. 
(Also check your QlikView server resources. As you are using NP QVP connections, overhead on the QV server, if heavily utilized, will impact NPrinting performance.)

And finally, finally promise. Check you have sufficient hard drive space on your NP server. If for some reason it is running low, you will need address that.

cc @QlikMo 

[QlikMo · Accepted solution]

Thank you Lech and Frank. I went through both your points but they did not apply. Very good points though and I have saved them for future checks.

The only other things I am looking at aas the cause is 

- Antivirus/Endpoint folder exceptions on both servers. Currently no exceptions are set up 

- Google drive - the local folder location that nPrinting saves that report to is also a Google Drive share (we used a folder on the C drive and not an entire drive for the Google drive software)

The good news is it didn't happen yesterday so it may be a one off but I do need to get the antivirus exceptions set up.

Thank you both

[David_Friend · Accepted solution]

@QlikMo yes definitely get the antivirus exclusions setup, I've seen those cause intermittent/odd behavior!!

[QlikMo]

I believe Antivirus/End point software was the cause. Other apps were randomly taking a while to generate. Once we put the exceptions in it all went back to normal.

Thanks everyone

[Frank_S]

Thank you @QlikMo for sharing the resolution!