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.


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.

  • Just yesterday this was raised to me by a different customer. I will discuss with our CM team. There are certainly ways to do it, but I don't think any is obvious...
    – Nuno Linhares
    Jul 16, 2015 at 19:06
  • Well, I hope it gets priority and is addressed :) Jul 16, 2015 at 21:19

3 Answers 3


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?

  • 1
    You can probably do a resolve ("see items to publish"), grab that list of resolved items and go through all binaries, add those up, then roughly estimate every page at 10K size and component at 5 K size (top of my head numbers), and get a rough estimation of what size the package would be?
    – Nuno Linhares
    Jul 16, 2015 at 20:43
  • @David I am already using a pragmatic approach by recommending 10-15 items per bundle, but this is not well received by the user. Jul 16, 2015 at 21:06
  • @NunoLinhares The issue is that there are some pages with over 50-60 binaries and there are few with 5-10 binaries. So, coming up with a unified recommendation is extremely difficult. Also, the see items to publish will show the pages, then we have to go through the page and parse the pages to find out items used, go get the binaries from a different system and then calculate the size. I think it is very similar to actually rendering the item and getting the package size which is atleast automatic. Am I misinterpreting your suggestion? Jul 16, 2015 at 21:12
  • Ah, users... Bless them :) Unfortunately, as I'm sure you know, it's a more complicated problem than maybe the user understands. @Nuno that might work well if your page & component sizes are fairly consistent. Still an estimate though... Very tricky if not impossible (considering that things can change after being added) to get an actual figure. I'm interested to hear what your team come up with :) Jul 16, 2015 at 21:15
  • I don't think the user needs to understand how hard this is, just that there is a limit (not Tridion's limit, to be clear). In the end, editors will still try to publish the total amount of pages, so 50MB is only limiting how much they'll publish at-a-time. For comparison, Outlook can limit attachments (e.g. 10MB per email) or give you a per-user quota. If there's no limit on \images maybe there really isn't a limit and the 50MB could be slightly increased accordingly. :-) Jul 19, 2015 at 1:05

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.

  • hi Alvin, +1, for suggestions. I am definitely looking forward to what Tridion comes up with or else I am thinking about capturing size of the image as an attribute of the image like height and width and then may be store on app data that you have suggested on the components. It is still going to be tedious to calculate, but if there isn't any other way then, this is the only option. On, # of binaries, I've seen a lot of enterprises with broad usage of WCM and # of binaries is definitely increasing :) Jul 20, 2015 at 18:47

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...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.