This example assumes that multicast connectivity exists and available bandwidth on the network is known. While not every aspect of a multicast deployment is covered in this example, it does illustrate the general thought process applied to multicast deployment.
The location of the EMS server and clients are very important to a multicast deployment. You must ensure that multicast packets can get to all network nodes intended to receive multicast data, and you must account for all bandwidth across the network and network segments that the multicast data traverses. While TIBCO Enterprise Message Service detects and reports general connectivity problems, it is generally much easier to determine if there is connectivity before testing an EMS deployment. Your network administrator should be able to help with this.
For this example, let us assume that we are multicasting two streams of data: a fast data feed to some high performance processes on a 1 Gb network, and on a separate 100 Mb network a slower stream to a number of desktop applications. This leads us to the architecture shown in
Figure 22:
Note that two separate channels using different interfaces are to be configured at the server, allowing the server to simultaneously multicast on a high speed Gigabit network and a slower 100Mb network.
Installation is straightforward, as described in the TIBCO Enterprise Message Service Installation. The only requirements above a regular EMS installation are:
Before sending multicast data, first the EMS server needs to be configured. Configuring the EMS server requires you to change some global settings in the
tibemsd.conf file, and to configure multicast channels in the
channels.conf file. After channels are configured, you enable topics for multicast by setting their
channel properties in the
topics.conf file.
console_trace= DEFAULT,+MULTICAST
The next step configures the multicast channels. In this example there are two multicast channels,
mcast-1Gb and
mcast-100Mb. The section
Sample channels.conf Settings below shows specific settings for these steps:
The maxrate parameter restricts the rate at which the server sends messages over the channel. See
Estimating the Maxrate below for a discussion of how the maxrate was determined.
When you have completed your channel configuration, the channels.conf file should contain the following lines:
In this example, we have set the maxrate properties using arbitrary network usage numbers to arrive at an estimate of network capacity. The process used to estimate the
maxrate can be described as follows:
These initial rates are for testing purposes, and these will be modified later to maximize performance. Remember the cardinal rule with multicast performance is that sometimes you have to
slow down to speed up. A rate that is too high will induce loss, which in turn causes messages to be resent, slowing the actual rate to something far below what your network is capable of.
After the channels are defined, you must set the channel properties for topics so the server will send messages using multicast to multicast-enabled consumers subscribed to the topics. The channel property is set in the
topics.conf configuration file.
In this example, we use two topics, feed-1Gb and
feed-100Mb. These topic names are arbitrary; the key is assigning the correct channels to the topics.
TIBCO Software also highly suggests that applications take advantage of the multicast exception listener to be notified of multicast related events, errors, and warnings. This is accomplished in two simple steps, illustrated in java code below:
public void onMulticastException(Connection connection,
MessageConsumer consumer,
System.out.println(e.getMessage());
To set up a multicast exception listener using the .NET API, see the
TIBCO Enterprise Message Service .NET API Reference, available through the HTML documentation interface.
It is valuable to know what EMS data rates the network can accommodate. If your application can handle data at least as fast as your network can, you will encounter the unusual situation where the network is your throughput bottleneck, which is
ideal—as long as those data rates meet your requirements.
Now that the server is enabled, you can test and fine tune the maxrate specified for the channels. This section describes one method for testing your settings.
4.
|
Launch the tibjmsPerfSlave sample program included with EMS:
|
It is very important to run the jmsPerfSlave application on every node that will receive multicast data. EMS Multicast must be tuned to perform at the level of the slowest receiver, or congestion and loss can occur.
When the trace messages indicate that multicast channels have exceeded their bandwidth, this indicates that the channel maxrate is too
low—your publisher is publishing faster than the channel’s
maxrate allows. On the other hand, when the
maxrate is too high, you will see errors indicating that loss is detected.
One key to a successful multicast deployment is ensuring that the EMS server does not overrun your applications with data. This frequently this means setting the delivery rates (the channel's
maxrate property) to a rate below what your network and EMS alone can handle.
Determining the maximum message rate that your slowest application can handle reduces the time spent during trial and error testing. If your applications can process data faster than the network can deliver it, you will have already determined the maximum rate from determining your network capabilities.
Largely, determining the maximum speed at which the slowest application can process incoming data is a trial and error process. It is often useful to programmatically determine an application's maximum rate of consumption. The multicast daemon buffers messages for slower applications, but this increases the latency of data and memory usage of the multicast daemon, and is not considered a sustainable condition.
Once you have determined network capabilities and multicast receiver rates, you can experiment with increasing (or sometimes decreasing) channel
maxrate properties to achieve maximum throughput. Finding the maximum multicast rate your environment can handle often requires more experimentation than anything else. Always remember that once the network has been saturated, throughput will drastically drop.
Unfortunately, operating systems are not normally tuned for high performance with raw sockets. There are a number of performance changes you can make; typically, these changes involve socket buffering and can yield significant increases in throughput.
However, operating system tuning for multicast falls outside of the scope of this document. The TIBCO Professional Services Group can provide assistance with advanced tuning specific for TIBCO Enterprise Message Service, and there are many resources on the internet for general tuning of operating systems concerning network performance.
Configuring multicast is specific to a particular network, and your configuration must account for traffic patterns and characteristics of nodes that are unique to your network. Consequently, the tuning parameters applied to a development environment may not be optimum in a production environment, and the reverse is also true. When migrating from one environment to another, it is important to remember that although the application and EMS architecture pattern may be identical, the network and application capabilities will need to be reevaluated through the repetition of the steps described in this section. Topic and channel definition names should remain the same, but rate, interface, and timeout parameters for multicast must be reevaluated.