4

I need to fetch Component data in a User Control from the Presentation Server, and I have 2 ways:

  1. First published the Component to Broker and then use the Broker API to fetch the content in the User Control.
  2. Publish the Component to the file system of the Content Delivery server in the form of an XML file and then fetch the content from that published XML.

I know that if I go for the Broker option, then there would be a server hit to DB, but also Broker provides caching. Whereas if I use the file system then there is no DB hit.

So here I am looking for a precise answer from some expert as I already used and familiar from both ways to fetch data.

Improve this question

2 Answers 2

Reset to default
3

It absolutely depends on what you are trying to achieve. If your components are going to be in millions, then it makes sense that you use the Broker Database and use Broker API (for Tridion 2009 and below) or Content Delivery Web Service (for Tridion 2011 and above). The reason is that it may become a problem if millions of files in the size of several Giga Bytes is available on the File System in terms of maintenance and backup of the same. Further scaling out will also be cumbersome specially if you are planning to use the DFS tool.

Further, regarding performance, Although Tridion Cache Channel Service is fantastic in providing a great performance yet it will not assure you that there will be no DB hits. However, it would be great to have it.

For the cases where you only have small number of components to publish - something like Navigation Components for Primary and secondary navigation, then it will make sense to publish them to File System instead of Broker DB

Improve this answer
2

My preference for data distribution is always to use the database, but not necessarily for caching reasons. While, yes, caching will help (btw, we will also cache Component Presentations stored in the File System), the single biggest advantage in my view is one of data consistency across servers.

When using a single server for Content Delivery, data distribution isn't much of an issue, but once you need to scale up (for either performance or availability reasons), ensuring files are updated simultaneously in a large server farm can be a pain. By using a single repository for this - like a database - you remove this possible bottleneck from your architecture.

This is a personal preference, not necessarily the best approach according to your needs. If either way works for you, then I'd certainly recommend using the database.

Improve this answer
3
  • but what if component holds only few contents and that need to use only in dotnet user control, also there is no issue of multiple server,
    – Nash
    Jul 23, 2014 at 12:00
  • Also you mentioned that there would be pain if we use the filesystem because updated simultaneously in a large server farm can be a pain, but this is also applicable in case of broker database because at the time of publishing you can publish component only in one server and at later stage rocopy will do the task for scale up data consistency across servers
    – Nash
    Jul 23, 2014 at 12:03
  • Typically with DB deployments you'll use one DB for N app servers, and if you have multiple DBs, then you'd use DB replication, which is much faster than FS replication, so there's less chances of having sync issues.
    – Nuno Linhares ♦
    Jul 23, 2014 at 12:32

Your Answer

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

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