Syndication tuning

While syndication is a vital part of keeping web content current, the same syndication strategy is not appropriate for every environment. Depending on how you have deployed Web Content Manager, you can use different syndication strategies to balance the currency of content with the performance environment requires.

There are several different means to manage how and when content is replicated to other servers. It is important to note that, as with any process, syndication entails a performance cost, and this should be taken into account when specifying not only the frequency of syndication but also the number of syndication relationships for any given server.

Syndication interval

The syndication interval controls the frequency of syndication while automatic syndication is enabled and can be used by administrators to put a cap on how often syndication occurs. Because up-to-date information is important to any web content environment, automatic syndication is enabled by default when IBM WebSphere Portal is installed. While the default setting for the syndication interval ensures maximum currency, you can choose to adjust the value accordingly if the currency demands of environment do not call for the shortest interval.

Interval setting	Recommended environments
10 minutes – 2 hours	Staging servers to delivery servers.
30 seconds – 10 minutes	Any environment that requires frequent replication, such as an authoring server to a staging server, a test server, or distributed authoring server. When increasing the syndication interval for environments where authoring servers are involved, be mindful that timely replication is often essential, particularly in collaborative authoring environments where multiple authors on different servers might be working on the same content.

Syndication types

Live items:

Live item syndication is mostly used when syndicating to a staging or delivery server. The following items are syndicated:
• Published
• Expired

Draft items, projects and items in a project are not syndicated.

Live and projects:

The advantage of using "Live and projects" syndication is to gradually syndicate projects to a staging or delivery server rather that waiting to syndicate all the items in a project after they all achieve a published state. The following items are syndicated:
• Published
• Expired
• Projects
• Draft items in a project

Draft items outside of projects are not syndicated.

All items:

All item syndication is mostly used when syndicating between servers within an authoring environment. The following items are syndicated:
• Published
• Expired
• Projects
• Draft items in a project
• Other draft items
• Versions
• Deleted items

Manual syndication

It is not necessary to wait for the syndication interval to elapse in order to perform syndication. Manual syndication can be used at any time to cause syndication to occur immediately. There are different ways to take advantage of manual syndication:

• You can use manual syndication in conjunction with the syndication interval to provide flexibility. For example, if you are using an increased syndication interval to optimize performance between servers, you can still perform manual syndication when you need to update content without waiting for the next syndication.

• If you require complete control of when syndication occurs, you can use manual syndication as the only means of performing syndication. For this approach, disable automatic syndication so that the syndication interval setting is ignored.

Publish and expire dates

Because the syndication interval is not based on a scheduled time of the day, it is not suitable for setting up syndication to run during off-peak times. The publish date and expire date are the preferred methods for doing this.

The publish date for each content item specifies the date and time when the content should be published to a website. After a content item is approved and the publish date is reached, the content item is queued for syndication according to the next syndication interval. By using the publish date, you can delay the publishing of content, effectively delaying its syndication. For example, if you are using a short syndication interval to ensure timely replication of most content, you can delay the syndication of less urgent content through the publish date for that content.

The expire date specifies the date and time when the content item should be removed from a website. As with the publish date, you can use the expire date to cause the syndication activity associated with removing the content to occur at a time when other syndication activity is less intensive.

For more information on the publish and expire dates in the workflow process, refer to Item status.

Parent

Syndication concepts

Related

Syndication overview

+

Search Tips   |   Advanced Search