best practice for Publication size / amount of pages

Florian_Lubbing
4 yrs ago
10replies
Answered

Dear community,

do you any experience to share when it comes to larger publication objects ?
We plan to set up a publication (for PowerPoint output) which may have up to 80 - 100 (!) pages (containing a lot of pages with pure text and various discover chart objects - lets say 50/50 ratio).

Should we expect performance issues or any other problems? Whats the best practice for such a setup?

Thank you very much,

Florian

- Philip_Augur
- 4 yrs ago
- Reported - view
Hi Florian,

It is impossible for me to know whether what I am about to describe had to do with my company's configuration/server "horsepower" or the software.

I had a report that was about 30 pages. Mostly tables, some charts, no dynamic text -- just some labels and footnotes here and there (fixed text). That ran well.

I then had to update the report (which was focused on the first calendar quarter) to add a Year to Date version of all the same reports, as well as the current quarter. So it doubled in size (plus a few new ideas got included). That did not work. What's worse is the whole publication became unstable/unusable, so I had to start over.

For clarity, this publication was many many underlying discovery objects, not a handful of discovery objects iterated over multiple members of a dimension, so it may not related to what you are doing. I have done other simple publications that then iterate and never run into trouble there.

Good luck!

Phil
- samuel_alma
- 4 yrs ago
- Reported - view
We've built numerous publications (PDF, Word and PowerPoint) and all have worked. Out largest template is 70 pages long - with every type of content item imaginable.

What you need to be aware of is this:

A large report does take longer to render. It should: 2-3 queries per template page over 70 pages is like running almost 200 queries per run. If you ran that for 50 slices, you would be executing 10,000 queries per batch! Personally, I would break up the package and do smaller reports - and it won't kill your data source. (I also think very long PowerPoint decks are a little unstable themselves when you open them in PowerPoint itself.)

The editing process is best done using 'prototyping'. That means building out a small example of the entire package and getting it right before expanding it out completely. This includes layout, formatting etc. It is much better than creating the entire report and then changing the design and layout over and over again. [One technical comment: Publish shares common queries if used multiple times. If you copy-paste items be aware that they are not 2 independent items, but rather conjoined elements. We found this effect after much trial and error. It turns out its not a bug, its by design for performance. We submitted a feature request to provide the alternative and I believe its on the near term road map].

Keep the formatting of content tight and almost exclusively in Discover or Illustrate. Doing adjustments in Publish is slower and can create inconsistencies. (Try and avoid the 'unlinking' option for discoveries).
- Florian_Lubbing
  
  4 yrs ago
  
  Reported - view
  Hi samuel alma ,
  
  I feel like I missed an important point here.
  
  You were saying:
  
  [One technical comment: Publish shares common queries if used multiple times. If you copy-paste items be aware that they are not 2 independent items, but rather conjoined elements. We found this effect after much trial and error. It turns out its not a bug, its by design for performance. We submitted a feature request to provide the alternative and I believe its on the near term road map].
  
  Can you please explain further what do you mean by that?
  Are you aiming that if copy&pasting a whole page or a single discover object, the copy is still the same discover object (unless the"unlink"-function is used)? - thats what I am aware of.
  Or is there any more magic happening ...;)?
- samuel_alma
  
  4 yrs ago
  
  Reported - view
  Florian L. If you copy a linked Discover, its the same item. Unlinking the item effectively makes it a stand alone one-off Discover inside the Publish template. Unlinking multiple copies of the original Discover *may* then create independent copies - although I'm not sure.
  
  Once the item is a one-off, the only way to access it is from inside the Publish template. That's why we think its way more efficient to create them as proper stand alone items and just link them into the template. This will allow you to open them independently and fix them directly if needed. Managing 40 discovers in a folder is easy (you can even open them with a single command from the content manager).
  
  If you use themes religiously, you can also eliminate complex format change making. You simply reopen the items and apply the updated theme.
- NPANS
- 4 yrs ago
- Reported - view
We have built several successful publications.

My biggest suggestion is to write all the required text in notepad, text editor or Word and then copy paste into the publication. The browser based text editor is a little temperamental.

Second recommendation is to put all the content into the template and then do the slicer wire up at the end.

Last thing, is that we totally underestimated the server resources needed. We were trying to render 500 reports a night on a small server (I think it was 8 core / 16Gb memory) that also hosted the data source (MS cube).
- Florian_Lubbing
- 4 yrs ago
- Reported - view
Hey guys,

thanks for replying and sharing your experience!
You named some important topics I already was wondering about!

Our report setting is more like an "annual report" which will be rendered from time to time for draft versions and the final document - so I think facing longer rendering times might not be our main concern. However, dividing it into smaller chapters (multiple publication objects) might be a good approach.

I already had some "wrangling" with the "temperamental" text editor NPANS mentioned and hope it would be sufficient enough to only have "raw" text inside the publication and do the necessary fine-tuning via PowerPoint later on.

samuel alma : are you recommending not to use the UNLINK-function? (It was the one I would have heavily relied on...).
This is because we optimally will start building the report with just a handful of discoveries - each page is showing content (graph, dynamic text and editorial text...) for a single element from our main dimension (lets call it "dimension 1").
My current approach is to set up a few template-pages that I can duplicate (especially for keeping format, position etc.), then unlink the chart from the duplicated page and select the next element from "dimension 1" within the underlying discovery
(...however, I don´t have a handy solution for the dynamic text by now ;)).

Here is a simple draft of the concept:

Example for templates 1-n (usable for most of the pages)

Duplicated Templates - each page is set up with one specific element from the main dimension

(What I am used to working with other BI tools is some kind of "page selection" I found hard to reproduce here)

I would appreciate your thoughts on this!
Thank you very much, best regards

Florian
- NPANS
  
  4 yrs ago
  
  Reported - view
  Florian L. take a look at the page repeater - its a good way to repeat the same page multiple times for different elements in the hierarchy. Its smarter than duplicating pages for each element uniquely.
- Florian_Lubbing
  
  4 yrs ago
  
  Reported - view
  Hi NPANS ,
  
  the page repeater is indeed a nice thought - however, each page also contains its unique editorial text which will be written directly via publish (no dynamic text)...so I fear it only gets the job "half-done" ;)
- samuel_alma
- 4 yrs ago
- Reported - view
The "unlink" function is focused on either creating a one-off analysis or for allowing the visual to be formatted in the publication uniquely, separately from its original design in Discover (effectively, the same reason). I don't think its primary purpose is to facilitate copy/paste.

I would build the variations in Discover (stick them in a folder), and simply add each one. It will give you more flexibility in the future and better content management options.

To keep formatting tight, use the rulers, snap to grid, master pages and the "guides". This is a better proposition rather than copy/paste of pages etc.

I don't understand you last comment on "page selection". Perhaps you can explain it.
- Florian_Lubbing
- 4 yrs ago
- Reported - view
Thanks again for your contributions!

samuel alma I think the main problem for me is getting used to the thought of having such a lot of single discoveries (for my concept likeley 40+ objects for this publication)...plus having them all saved (spammed :P) into the CMS, plus dragging and dropping each object into the publication...

Then I fear the moment someone wants "the text font to be +1 point taller" or switching "the dark blue bar into a light blue" ...forcing me to touch each and every discover object again (however, the UNLINK function doesn´t solve this problem either ;))...

What I mean by "page selection" is that I was hoping to be able to stick with a few discover objects, duplicate my page templates as needed and then select for each page by which element of my dimension the content should be shown.

In Present, I realized a similiar szenario by simply adding a new slicer for each page which has a "handpicked" set of elements via the advanced settings

ATM I don´t see a way to achieve this in publish (slicer option here is meant to be used in another way...).