We are running SDL Tridion 2011 SP1 for publishing a Java (JSP) based website (IIS 7.5 & Tomcat 7). The website does not use Dynamic Content Broker and rather uses local file system for storing published contents. So far the website was running off a single server. Now the client wants to deploy High Availability and Load Balancing. So we have configured the published files to be stored on a shared network location which is accessible to both web servers.

Since there is no Dynamic Content Broker the metadata for linking is stored on the file system in CSV files. As these CSV files are stored on a network share, we think this is affecting the performance (reading a number of CSV files for each page request over the network). We would like to know if it is possible to switch to Dynamic Content Broker ONLY for storing PageLink & ComponentLink metadata and if this would improve the performance.

1 Answer 1


The short answer is 'yes' and 'yes'.

The long answer: in your cd_storage_conf.xml you can specify the item type mapping DynamicLinkInfo to use a Content Delivery Database (FKA the Broker DB). While keeping all your other mappings to file system, this ensues that only your linking (i.e. Component, Binary and Page) info will end up in the CD DB.

Regarding performance - the access to the linking info stored in CD DB is cached by the Broker API (internal memory object cache) using a LRU policy. This means you basically read the CD DB a lot less frequently than you access your file system CSV link info files in your current situation... a definite performance boost.

  • 1
    Are file based lookups not cached?
    – Jan H
    Nov 14, 2013 at 22:15
  • Very good question Jan. My hunch is they are not, but I'll double check. Nov 15, 2013 at 1:34
  • I believe filed-based (delivery-side) metadata (including linking info) was deprecated in SDL Tridion 2011 SP1. But was CSV an option or is that a custom approach? Nov 15, 2013 at 4:35
  • CSV is still an option and we've been using it for quite a while now. Nov 15, 2013 at 6:25

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.