Execution Time Disparity in Generating Different Report Formats of same report in QlikNPrinting

[ranidas]

Hi Team.
We need assistance regarding the significant difference in execution times when generating the same report in varying formats.

Our process involves creating a report using a DOCX template. We've set up a task to generate documents in both DOCX and PDF formats. When executing the task in DOCX format for the first time, it noticeably consumes a considerable amount of time to generate the report.

However, immediately after completion of docs file , we have  generated the PDF file, the subsequent generation of PDF files only took approximately 2 to 3 minutes. We're curious about the internal execution mechanisms that contribute to this time discrepancy between the formats.

Your insights and guidance on this matter would be greatly appreciated.

Qliksense May 2022
QlikNprinting MAY 2022 SR3
@Lech_Miszkiewicz, @Ruggero_Piccoli 

[Lech_Miszkiewicz · Accepted solution]

Hi @ranidas 

I will not jump into conclusions as I dont know your exact setup, but...

• if you have single task and you send in it:
  • word report 1 stored as docx
  • the same word report 1 stored as pdf

then time spent to produce both reports is mainly to produce report 1 as pdf is just a print of docx. 

Have you done testing of what will happen if you run pdf report only by itself? I bet it will take similar time as production of first docx report.

If setup is different and you use 2 different tasks then another factor could be cache effect of Qlik Sense (in case app is large and responds slowly that can help). There may as well be a factor of loading Qlik Sense app to the Qlik engine memory when app is opened for the first time.

Bottom line is (i think) - the actual format (docx or pdf) may not play a role but all other factors likely are: order of execution, app warming, cache effect.

cheers

Lech

[Ruggero_Piccoli · Accepted solution]

Hi,

I agree with @Lech_Miszkiewicz , plus please note that the generation time could depends on many things. Some are listed in the page https://help.qlik.com/en-US/nprinting/May2023/Content/NPrinting/DeployingQVNprinting/Performance.htm. The generation time could depends also on the workload of the connected Qlik Sense Server. So monitor also it. 

The first execution of a publish task could be slower than next ones and I think this is your case more than a difference due to the output format that could exists. 

Did you noticed this behaviour at every execution? Did you enabled the Audit Trail to monitor the duration of tasks and other parameters? I suggest to start by checking the details of the task executions page to see more details. 

Best Regards,

Ruggero

[ranidas]

Hi @Lech_Miszkiewicz  and @Ruggero_Piccoli,
I wanted to express my gratitude for your valuable inputs. Your insights have been immensely helpful. I took the time to go through the links you shared, and they provided further clarity on the matter.

As highlighted, I've been working on a single task involving reports generated from a docs template. These reports are produced in two distinct formats - Word and PDF from single task.

One observation I've made is that the initial execution of either format, whether it's PDF or Word, tends to be slower compared to subsequent executions as rightly mentioned by ruggero. My assumption is that during the first execution via connection refresh, there's an upload or update of metadata. Subsequent executions seem quicker, possibly because the necessary data is already prepared for use.

However, a lingering question remains: when we develop a report using a specific template (for instance, Word or Excel) and extract it in a different format (such as HTML or PDF ), I'm curious about the internal process. Does it function akin to capturing a screenshot, or is there a different underlying mechanism at play?

I appreciate your insights and expertise on this matter .

Thank you for your time and support.

[Lech_Miszkiewicz]

HI @ranidas 

As you know NPrinitng is not open source code tool so obviously I will not be able to share how things work internally as that is kept secret and is not public knowledge.

What we know though is that there are different elements working depending on the source document being QlikView or Qlik Sense. As you should know for QlikView we need QlikView desktop client installed as that is used to communicate with the QlikView app objects. For Qlik Sense we dont have a typical client, but instead we have web browser process (webrenderer) which seems to do heavy lifting job of extracting images/data. 

I am not Qlik employee but I am long term Qlik partner so I have been through good/bad/ugly with Qlik and NPrinting.

Information I have provided on this subject are only my assumptions purely based on observations and history of working with tool so take that information but do not consider this beeing 100% truth as I am not 100% sure for myself. 

I dont think Ruggero can add more to it given that he is also bound by NDAs

cheers

[Ruggero_Piccoli]

Hi,

On the first run performances compared with following, there are internal optimizations. Qlik NPrinting "supposes" that if you create reports from a connection you will create other reports from the same connection or so after so it keeps communications open and restarting is faster. This is the reason why, for example, after the end of a task execution you will still see Qv.exe processes running. Keeping them alive means not need to wait the reopening when next execution happens. 

Office reports are generated by a library and this is why you need a local installation of Office only in the computers used to develop templates but not in the Server or Engines used to generate final reports. If you create a normal Word document you can save it in HTML format. It is something similar but we always suggest to develop the template of the same format you want to have the output. For example, if you want an HTML report create an HTML template because HTML generated from Word is not so optimized and you cannot edit the native code. 

Best Regards,

Ruggero