Very very very bad performance NPrinting 2020 (and 2019) through QVP for QlikView

[i_shamaev]

We are moving to the new version of NPrinting (2020) from the old version NPrinting 16. 

We started migrating our nsq projects to the new version of NPrinting. Encountered poor performance through a QVP connection.

However, we can 't use a local connection because nprinting sends old data from the previous open qv.exe document.

Performance degradation compared to the old version is up to 15 times ( for example, instead of 1 minute, reports are sent out in 15 minutes). We sent all the information through a partner in Russia, but progress on solving the problem is very, very slow.

😓😓😓😓😓😓😓

It feels like you haven 't tested your product! At the same time, you encourage everyone to migrate to the new version!

[Ruggero_Piccoli]

Hi,

We care a lot but we need to test each single case and we need the time and the cooperation to test. 

As usual we will share the solution here in the community post and/or in all other official documentation like the help site or the release notes in case we will fix issues.

Best Regards,

Ruggero

[i_shamaev]

We stopped our migration project from NP 16 to new NP 2020. We are waiting for a normal product.

We will wait for the results from R&D...

[Ruggero_Piccoli]

The R&D team is working on your issue.

The support team will contact you when there will be something new. 

Best Regards,

Ruggero

[i_shamaev · Accepted solution]

Thanks so much for solving the problem with slow qvp connection. Solution in the image

We should have unchecked setting in QlikView App

[T0mm450-3rc0l3]

No why? If you have problem with NP to QlikView or with other parts of the product that are performance related, I really care for them.

[MikeW]

Be careful with that setting though. Make sure you are getting the updated qvw.

I think qvp is slow because it seems to be doing a cache regeneration when there is new data. Unchecking this disables the automatic refresh of new data if the qvw reloads. That may or may not be something you intended to do.

I've had the most success when I try to minimize the connection cache regeneration time, or generate the cache before running multiple tasks on the same connection.

[T0mm450-3rc0l3]

Hi @MikeW , unfortunately it seems to be more something like a malfunctioning. I was testing without any reload during the verification. Just checking/unchecking the box gives different results.

If @i_shamaev  needs to have push from server after reloads, he can enable the option in the same page, in the upper part "Client initiate refresh..... automatically" and under it "Just do it.".

That seems to give the same effect.

These options are to be used JUST when using QV Reloading, and if you are going to save the document manually, without performing a reload you can make NPrinting unstable for now.

[MikeW]

I tested the combination of Client initiate refresh...automatically and just do it, then unchecking enable push from server. That didn't pick up the latest data when I just created a report with =ReloadTime() formula. I am using QMC to reload and publish, but I have the option to allow more than 1 copy of document in memory enabled.

Would you be able to test with these settings to confirm if it does indeed speed things up and also get the latest data?  I guess you can just do a partial reload with an immediate exit script and that will update the reload time. 

[T0mm450-3rc0l3]

@MikeW indeed we are having automatic tests testing exactly those options, but with one difference: we don't allow more than one copy of the document in memory on the server.

According also to this article https://support.qlik.com/articles/000003052 allowing more than one copy can have unexpected results. And this is the reason we did not enable that option. 

Moreover, those settings avoid the delays that @i_shamaev  was experiencing. These delays are related to the specific usage of a single method and so they are not a panacea to solve every performance problem that you can find.