I'm testing NPrinting 17.1.2 in order to migrate a current NPrinting 16 enviroment.
But, I have detected some issues so far:
- There are multiple QV.exe processes running on memory, even when the publish task has ended. This is a real problem, because with every task, there are more new QV.exe processes and the available memory is running out, until there is not more. This problem happens with any kind of report (Pixel Perfect, PPT, etc)
- How can I check the progress of a publish task?... how much time took from the beginning to the end?... how can I read the logs?
I will update this post with any new discoveries, but, there is information about this issues that you guys could share with me?
Thanks in advance
Had you solved this situation? We have the same issue. I guess it´s a default situation and going to open a case to Qlik to be able understand this situation.
Unfortunately, we didn't have any possitive answer. This is the transcription of a cuestionarie send to Qlik Support, and honestly I'm not happy with the answers:
In the documentation, is it recommended that NPrinting had a dedicated server for this reason.
"This behavior imply that my server, on the time, suddenly will lack of any available RAM? If I add more qvw files as datasources, and I add more reports to NPrinting, the current server will be not enough?
--Yes, NPrinting will continue to open qv.exe instances for each core available on the server and each instance will consume RAM while open.
Even if this reports are not on execution at the same time? or its execution is generated monthly, weekly, etc?
--When the core limit is reached, it will then start to re-cycle the active sessions.
How does work the NPrinting memory deallocation?"
--This information has been provided from R&D
While the name is NPrinting 17, this is basically a 1.0 product with a complete new architecture and design so a lot of these questions have not been answered yet being such a new product."
We have decided to try using QlikView Server as datasource, instead of the local qvw file, because QVS may be has a better RAM comsumption control. May be this could be a workaround for this.
We are testing NPrinting 17.2 and so far, the behavior is the same as 17.1.
I hope you have better news, and can share it with us.
The upcoming release is addressing open QV.exe session "issue".
On the other hand i do not think it is a issue if:
I am on 17.5 (waiting for April/May 2018 version to upgrade). What if you have all those things in place, that is, I have QV on one server and NP on another, and I have taken my qvw and limited it by not only the data I need to report on but also took out any tabs I didn't need. My publish tasks run way too long and inconsistently...for one task for example...one day it takes 20 mins, on another it can take 2.5 hours, and there are times I decide to kill the task because no progress has been made after 4 hours. The reports have all the bells and whistles like cycles, levels, paging (and only a few users get them). If stripping down my qvw in combination with these features works this poorly, this tool won't work for us long term as we have even more complicated reports that will go to many more users.
I am aware that report generation speed is an issue and i have been also vocal about it. I am especialy pointing here towards qvp connection which technicly - long term - is more stable, but has this lag with report generation process!
From my experience though there are some things which can be done within templates, for example:
Did you observer QlikView server performance once NPrinitng is doing report generation? How does you CPU and RAM look like? Is it spiking very high or within reasons?
Also NPrinting server & engine configuration - especialy for QlikView. I trust you are fully aware of the below instructions from help documentation and recommendations regarding number of cores for engine running qvp connections:
I am also facing the same issue here I am using version February 2019 (220.127.116.11), everyday one plus qv process running in background when i return after Weekends.
This is actual a big problem. Any work around or something to solve it temporarily until Qlik gets a solution for it.