I am new to both Tridion or DD4T.

Our application is making large number of calls to Tridion to retrieve one ComponentPresentation at a time. It is slowing down the page load.

We have already enabled Tridion Cache & we are caching component presentations. Although that reduced the load times, they still need to come down further.

Right now we loop through the component uris & retrieve component presentations, one at a time. Is there a way to load all the necessary Component Presentations in one call to Tridion ?

I looked through org.dd4t.providers.impl.BrokerComponentPresentationProvider and com.tridion.dcp.ComponentPresentationFactory, but I couldn't find any method that takes a collection of ComponentURIs & returns all the matching component presentations. Is this deliberate ? Is there a way to get what we need ?

  • 1
    Are you sure you have caching working properly? If you're serving them from memory and it's still not fast enough.... Nov 7, 2016 at 10:15
  • I think so, I am able to see the cache object count in DD4T-Dependencies & DD4T-Objects caches when I look at Visual VM. Nov 7, 2016 at 17:26

1 Answer 1


See my previous answer to this question https://tridion.stackexchange.com/a/15795/25 from a few weeks ago, which is suspiciously similar. There are no methods in the API to retrieve multiple ComponentPresentations unless you can utilise Keywords from a taxonomy.

Although that reduced the load times, they still need to come down further.

What are the current times and what do you need to achieve? Where and what are you caching (you can enable/disable caching for different ItemTypes)? What are your server specifications? How & where are they hosted? Are you counting first or subsequent request scenarios? There are potentially lots of factors at play here besides the CMS. If you genuinely need a faster response than your system can provide perhaps you can implement a storage extension, such as SI4T, to help you?

  • 1
    Last time I bothered measuring DCP load times, it was very close to 0ms when coming from cache. Definitely recommend writing a couple of test pages that measure this.
    – Nuno Linhares
    Nov 7, 2016 at 14:28
  • To give you the proper numbers I'd have to profile our QA environment which I am still in the process of getting setup. Based on the execution times I see in the instance that runs on my laptop, the calls to Tridion are the slowest ones. The slowest page takes 25 seconds in QA. While that is no entirely because of Tridion, it contributes a significant part of it. As far as your other questions, I am looking at the biggest culprit first. So apologies if I don't have answers to those. I think my question is answered however. TY. Nov 7, 2016 at 17:36
  • As per Nuno's comment, are you looking at first or subsequent requests? Caching will, of course, not help you for the first request, but if the items are being cached correctly then subsequent requests should be much faster. Nov 7, 2016 at 17:39
  • I looked at QA after considerable use, that is what bothered me. Nov 7, 2016 at 17:40

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.