Why would previewing a report in NPrinting 17 take so long?

[pover]

Hello,

When I preview a report in NPrinting designer, the preview takes 10 minutes to appear.  Maybe my point of comparison is wrong, but I can open the QlikView source app, calculate the source table and export it manually to Excel in 1-2 minutes.  Any idea why the preview is taking so long, or any idea how I can debug this?

Thanks, Karl

[Anonymous]

Hi Karl,

When I have experienced extended rendering time for reports, it is generally because of the volume of data that has to be processed.  I use QVW apps that are 4-5 GB in size with 100's of millions of rows of data.  If I don't reduce that data in my QVW by making some selections, I have found that running some reports can take 10-15 minutes.

I can't speak to how much more efficient 17 is then version 16.  I am still using version 16 and the way filtering works in this version is this.   If you don't use any current selections, then Nprinting brings across the entire data set from Qlikview and then filters the data on the Nprinting side prior to rendering.   When you make selections, Nprinting only brings across the possible data using the selections and renders from that set.

So, I would run a task with all of the data and it would take 10 minutes.  If I made current selections, it would render in 30 seconds.  This was the case with preview, tasks and schedules.

So, try making some selections and see if you get better results. 

[Anonymous]

Hi Karl,

Can you give more specifics about the type of NPrinting 17 report you are trying to preview:

- format (Powerpoint, Excel, etc)

- features employed (pages, levels, etc...)

- type, count & size of source objects used from the underlying QVW?

[pover]

Mike, I would understand waiting 10 minutes to generate that report if I were working with such a large file or a complex report, but the QVW file is 32 MB.  To answer Kyle's questions, the format is XLSX.  I'm only using fields.  If I try to use pages it warns me that it will take more than 10 minutes and stops the preview.  There's only one source object that is a straight table with 29 columns (3 dimensions and 26 expressions) and around 10,000 rows and has a QlikView calc time of 3 seconds.  It takes me manually about 1-2 minutes to open the QVW doc, open the tab and export the excel.  The logs in the programdata folder don't tell me much.  I don't know if there are other logs or a configuration I'm missing.

Karl

[Anonymous]

Hi Karl,

Considering your data model, I am curious what your goals are and how Nprinting helps?  It seems you are just doing a data dump so that it can be manipulated by another process.

My next step in the troubleshooting process would be to temporarily disable some of your expressions and see what effect that has on the results.  Perhaps, try with 3 dimensions and 5 expressions and see if the response time is adequate.  You could clone your object, so you are not messing with the original.  I am speculating the large number of expressions is contributing to your latency.

[Stephen_Jasionowski]

Karl -

Our of curiosity, does it take you the same amount of time if you run a task with same report? There is a timeout message that can occur during previews that recommends you run the report in a task instead.

I fully agree that it shouldn't take this long to run the preview for a simple report from a simple QVW, so if the behavior is specific to the preview and not a task, please log a bug with Qlik Support.

[pover]

Hi Stephen,

I, like many others will probably do, blew off the whole idea that the NPrinting service user has to be different than the QlikView service user.  So, when I had problems re-generating document cache, I discovered that was one of the symptoms of not using a unique user for NPrinting was exactly that.  I changed the user of the services, but discovered that my tasks weren't finishing correctly, so I decided to do a complete reinstall with the unique user in case there was somewhere else that user should be used.  After the reinstall, I´m having issues with the RabbitMQ message broker being unreachable, but I'm going to work through the troubleshooting documentation (I love good troubleshooting guides) to fix that.  Once that is done, I will test the preview against the task.  The slow preview issue has always been a problem since the first install, but let's see what happens after I correctly install it with its own user.  If I still get the same problem, I'll contact support.

You've done a great job with the product and I´m excited to see where NPrinting 17 is going.  Also, the customer has loved it so far, so I'm going to stick with it until I figure it out.

Mike, the user case is for a group of 400 sales reps spread out across all americas where internet connection outside the office is not always an option, so we need to make sure they get a few key reports delivered to their inbox every morning.  The 3 dimensions and 39 expressions are to be filtered by sales rep and the table is to be converted into a pivot table.  I will continue to debug the issue after the reinstall.

Thanks, Karl

[#8]

We have recently installed NPrinting 17 and have also had difficulty with the preview button. I have had previews reach the 10 minute time-out limit in reports associated with both large (900 MB) and small (6 MB) .qvw files. Without the ability to preview the report, I am spending a considerable amount of time between making a change and getting feedback. It's worth noting that this is my first experience with NPrinting, so I am in great need of that frequent feedback.

Not sure if this is related, but we have also had trouble getting a new connection to move from "Generating" to "Generated" status for particular .qvw files -- some large and some small -- while other .qvws will connect just fine.

Any advice would be greatly appreciated.

[gwoodard]

I am having problems with the Preview speed on 17.1.   Did you ever figure out the Preview timeout issue?

[wadesims]

I have had success with creating a smaller document with only the charts and related tables loaded that are needed for the NPrinting report / application.  We tend to have multiple fact tables rather than a single fact table with dimensions in a star schema and this approach seems to have helped with this particular issue in the recent past.