The following explain various scheduling issues:
Policies are scheduled according to local times. TED objects are scheduled according to an offset from Greenwich Mean Time (GMT).
Policies example: If you are residing in Utah and set a policy to be executed at 5 p.m. Utah time, it would be executed at 5 p.m. local time in Utah for servers residing in Utah. In California, it would execute at 5 p.m. local time in California. In other words, setting a time of 5 p.m. for a policy makes it execute at 5 p.m. local time wherever the servers reside.
TED example: If you are residing in Utah during Daylight Saving Time and set a TED object's schedule for 5 p.m., it would be executed at 5 p.m. local time in Utah. In California, it would execute at 4 p.m. local time (5 p.m. in Utah) for servers residing in California. In other words, TED schedules are relative to a GMT offset that makes the TED schedule execute at the exact same moment worldwide.
Distributions are anticipated to occur during off-peak hours. For some networks, it is possible that this scheduling window could be very short. Other systems on the network can also use off-peak hours for processing, such as backups.
You might have instances where the limiting factor is available time; therefore, the critical condition is how fast the Distributions can take place, regardless of the resources consumed. You might need to experiment to determine the best relationship between time and resources.
The Randomly Dispatch During Time Period option is available for each of the schedules (Distributor, Subscriber, Channel, and Distribution). It is used in conjunction with a time window (Start and End times) that you can set for a Daily, Monthly, or Yearly schedule type.
Randomly dispatching causes the scheduled action to run at any time during the window for the day. This helps load-balancing on servers. However, random-dispatched schedules can be confusing if you are expecting an action to take place immediately.
The following describe the issues for the Randomly Dispatch option:
You can use the Randomly Dispatch option for Distributor Refresh schedules to load balance Distributor refreshes from eDirectory. This is useful to minimize the network traffic that can be caused by many Distributors trying to read eDirectory at the same time.
Be sure to coordinate a Distributor's Refresh schedule with that Distributor's related Distributions' Build and Channels' Send schedules.
The Distributor's Refresh schedule should be determined by how frequently TED information is updated in eDirectory. For example, how often new Distributions are created, properties of existing Distribution objects changed, new Channels are added, and so on. The Distributor cannot know of changes made to TED objects without re-reading eDirectory. An eDirectory refresh should finish before the Build and Send schedules begin.
IMPORTANT: Do not refresh the Distributor more often than every five minutes. The following can need up to five minutes to complete their processes: Distribution building, eDirectory replication, and tree walking (when no Search policy is defined).
If you are using the Randomly Dispatch option, you should consider the End time for the Refresh schedule when setting the Start times for the Build and Send schedules.
You can use the Randomly Dispatch option for a Distribution's Build schedule to load-balance the Distributor's work in building Distributions. This becomes more necessary as the number of Distributions for a Distributor grows.
Be sure to coordinate a Distribution's Build schedule with its Distributor's Refresh schedule and any related Channels' Send schedules. A Distribution build should begin after the Refresh schedule ends and finish before the Send schedules begin.
IMPORTANT: Do not refresh the Distributor more often than every five minutes. The following can need up to five minutes to complete their processes: Distribution building, eDirectory replication, and tree walking (when no Search policy is defined).
If you are using the Randomly Dispatch option, you should consider the End time for its Distributor's Refresh schedule when setting the Build schedule's Start time; and, you should consider the End time for the Build schedule when setting the Start times for the Send schedules.
You can use the Randomly Dispatch option for a Channel's Send schedule to begin sending its Distributions to Subscribers randomly within a scheduling window. Each Distributor that has Distributions in the Channel calculates a random time between the specified Start and End times to begin sending its Distributions. This helps to balance the distribution workload for the network over a period of time.
For example, Distributor A and Distributor B have Distributions in a Channel. Each Distributor would calculate its own random time to begin sending its Distributions.
Another use of the Randomly Dispatch option for the Send schedule is if you have many Channels and you want all Distributions for all Channels to occur between 10 p.m. and 4 a.m. Using the Randomly Dispatch option in each Channel would allow you to disperse Distribution sending times for all Channels over that six-hour period of time.
If you are using the Randomly Dispatch option, you should consider the End time of each associated Distribution's Build schedule when setting the Send schedule's Start time; and, you should consider the End time for the Send schedule when setting the Start times for all associated Subscribers' Extract schedules.
You can use the Randomly Dispatch option for a Subscriber's Extract schedule to balance the Subscriber's work load in extracting Distributions.
If you are using the Randomly Dispatch option, you should consider the End times for the Send schedules of the Channels where the Subscriber is subscribed when setting the Start time for the Extract schedule.
Your Distributor can start sending Distributions to Subscribers throughout the scheduling window, according to the associated Channel schedules (see TED Object Scheduling Issues).
Use the Daily, Monthly, or Yearly schedule with the Randomly Dispatch option, in conjunction with the Maximum Number of Concurrent Distributions option, to help with load-balancing for Distributors. This spreads the network traffic that is caused by sending many Distributions over the entire scheduling window.
The following information concerning time zone offsets is from the perspective of the Channel object. However, this information is applicable to all TED objects that can be scheduled.
Because a Channel is an object in the tree that is not associated with a specific server, the Channel's time is always set to the local time zone of the workstation that is running ConsoleOne® and setting the Channel's schedule.
For example, if you (the administrator) live in New York City, the local time for any Channels you schedule from there will be local New York time.
If Distributors in different time zones from the Channel have Distributions in that Channel, the Distributors will need to send their Distributions according to the Channel's local time schedule. For example:
You should use a time zone offset to determine the true local time when the Distributor can send its Distributions. Also, because a Channel's schedule determines when a Distribution can be sent, you must make sure the build schedules you set for your Distributions will occur before a Channel's schedule.
The World Time Server is a Web site where you can determine the time difference between any two locations in the world.
As you look at the site, note the following:
To use this site to calculate time differences between TED locations,
Click the location for one of the TED sites.
Note the time, day/date, GMT offset, and whether Daylight Saving Time is in effect (for future reference).
Click the location for another TED site.
Note the time, day/date, GMT offset, and whether Daylight Saving Time is in effect.
Repeat this process for all of the TED locations where you want to coordinate schedules.
Using the information you have gathered, calculate the time differences between the TED locations.
Taking into consideration when events will be taking place locally at the various TED locations, configure the appropriate schedules using the time differences.
As an example,
If you wanted the Distributions to be sent later in the evening in Hawaii, the Channel's time window would have to start later than at 1 a.m. in New York. For example:
When you set up your Channel schedules, you need to consider which object's time window is more important. For example, it might be more important for the Distributor to be sending Distributions during off-peak hours. Therefore, using the New York and Hawaii example, to have the Distributions begin sending after midnight Hawaii time, you would need to have the New York Channel's start time set to 6 a.m. or later.
A Distribution can be set as Active or Inactive. Inactive is used when you are building a Distribution because you want to keep it inactive until it is ready to be sent to a Subscriber. The Active check box is found on the General tab of the Distribution object.
We recommend that your Channel be set to Inactive until you are ready to begin distributing your Distribution packages. This will prevent Distributions from being sent inadvertently.