Calculate package size when an item is added to bundle

Question

Our users started using Tridion bundles capability to club items which need to go together for time sensitive publishes. One of the challenges that we are facing with the usage of bundles is that it is very difficult to set a package size limit for the transport layer which sends the package to deployer via an https request. Currently, we have set the request size limit as 50MBs, but recently couple of bundles failed because they exceeded 50MBs. Increasing the request size limit is an option that I am not very positive on, since there isn't any limit to what the user can do. Also, short term I have recommended to use 10-15 items per bundle, but that restriction is causing lot of issues with the users since they have to create multiple bundles for a content release supposed to go together.

Question:

Is there a way to calculate the package size ahead of time so that we can let the users know that you cannot add anymore items to the bundle since it is going to fail at the publish time because of package size limit that is set.

I know that if we pre-render the package using advanced publish options or write event system code to trigger publish render on every item add to bundle, I can use filewatcher and capture the package to know the size. But, that seems a bit overkill since every time an item is added, I will have to trigger rendering. Is there an alternative way to find the package size. Has anybody faced a similar situation and what probable options are there for handling this scenario.

We are using Tridion 2013 SP1 and we have a fully scaled architecture, where we have separate CM and Publisher servers.

Answer 1

I've seen a similar issue too, but with a different failure point - possibly the same customer Nuno mentions in his comment. I'm not saying it's impossible, but it may be quite complicated to determine an actual package size.

I imagine you'll have to trigger some kind of publish or preview, as it's templating that affects what content and binaries are actually published and therefore the package size.

I don't recall it being possible to preview a bundle, so you'd need to resolve the items that are in it to the actual publishable items and preview each one, and you might need to de-duplicate any common items that are published (Binaries, DCPs).

Instead of previewing, you could set up a separate (local?) publication target and send a test publish job to that, but you'd need to wait until the job is at least ready for transport to get an idea of the package size, plus you'd have to capture that package somehow (Filewatcher maybe, as you say). If the rendering takes any significant time and you're waiting for it to finish before providing feedback to your users then their experience may suffer (Nobody wants a 3 minute wait while trying to add something to a bundle).

Final thing I can think of right now is that the package size can also change between the time something is added to a bundle and the time it's publish. Templates, components, binaries, pages, linked components etc. can all change significantly.

You could try a slightly more pragmatic approach and figure out what an average page and/or component produces in terms of package size, then somehow warn the user that publishing may exceed the limit?

Answer 2

If we can "bake" or "fry" for rendering, how about size calculation?

• Calculate size when adding an image or during the last publish
• Store this somewhere (AppData for the page or Component)
• Then maybe visually indicate how close a Bundle is to the 50MB limit (real-time or with a button to calculate the size).

Alternatively, consider a "split bundle" kind of extension or a way to separate the items (e.g. workflow or automation to break the items up).

Optimize Images?

I'd also confirm how many items editors typically publish. 15 pages under 50 MB suggests roughly 3MB on average per page (ignoring the HTML and XML in the package). There might be room to adjust the content model, optimize images, or change templating/resolving to skip images that haven't been updated since last publish.

A page with 50-60 binaries sounds like a gallery or documentation page of sorts. External Content Libraries or even MediaManager could help if available as well.

Answer 3

Seeing how this strongly ties in with your other question about publishing and bundles I would suggest using an event system to intercept publish operations on bundles and break them up into individual items. You'll lose the transactionality of bundle publishing but also the problems of increased package sizes (and your bundle will publisher in a shorter amount of time assuming it's the only item being published).

Note that breaking transactionality of publishing CAN be a very BAD thing so make sure all stakeholders involved understand the consequences of this decision...