To configure the server to deliver live media, complete the following task:

 Combine audio samples

To configure the server to deliver recorded media, complete the following tasks:

When a stream is requested from the server, segments of the stream are stored in a cache on the server. As long as the cache has not reached capacity, the server places segments in the cache. Each time a stream attempts to access a segment, the server checks the cache. If the segment is available, the server gives the stream a reference to the segment for playback. If the segment is not available, the server retrieves the segment from its source, inserts it into the cache, and returns a reference to that segment to the stream.

When the cache is full, the server removes unused segments, starting with the least recently used. After removing all unused segments, if there still isn’t enough room for a new segment, the server notifies the client that the stream is not available and makes an entry in the core log file.

If you have cache-full events in the core log file, increase the size of the cache or limit the number of streams playing. For more information about the core log file, see Monitoring and Managing Log Files.

1. Open the RootInstall/conf/fms.ini file.

2. Edit the SERVER.FLVCACHE_MAXSIZE parameter.

   This is the maximum size of the cache, in megabytes. The default value is 500. This value shares memory with the running process and has a limit of 2 GB in Windows and 3 GB in Linux.

   The size of the cache limits the number of unique streams the server can publish. To increase the probability that a requested stream will be located in the recorded media cache, increase the value of SERVER.FLVCACHE_MAXSIZE. To decrease the amount of memory the server process uses, decrease the value of SERVER.FLVCACHE_MAXSIZE. While a large cache size is useful, Adobe recommends that you ensure that your total system memory usage does not exceed the process limit of your OS. Consider memory limits and desired memory and stream performance when utilizing the memory cache.

   Note: Cache settings have no effect on live streams, as live streams do not need or utilize the cache.

3. Restart the server.

Streams break into chunks as they are written to the network. You can specify the size of a chunk. Large values reduce CPU usage because there are fewer writes. However, large values can delay other content on lower bandwidth connections. The larger the content size and the higher the bandwidth of the receiving connection, the more benefit is gained from larger chunk sizes.

1. Open the Application.xml file.

2. In the Client element, set the OutChunkSize element to a value between 128 and 65536 bytes. The default value is 4096 bytes.

   For more information, see Application.xml file.

3. Restart the server.

Sending aggregate messages reduces CPU usage and increases server capacity. You can configure applications to deliver aggregate messages to clients running on Flash Player 9.0.60.0 and above. When this setting is disabled, the server breaks up aggregate messages into individual messages before delivering them to clients.

1. Open the Application.xml file.

2. Locate the following XML code:

   <Client> 
       ... 
       <AggregateMessages enabled="true"></AggregateMessages> 
   <Client>

3. Make sure that the enabled attribute is set to true (the default).

4. Validate the XML and save the Application.xml file.

5. Restart the server.

To handle more connections while broadcasting a live stream, combine audio samples.

1. Open the RootInstall/conf/fms.ini file.

2. Edit the following parameters:

   • APP.SUBSCRIBERS: If there are more than this number of subscribers to a stream, audio samples are combined. The default value is 8. To increase live streaming capacity, set this value to 1.

   • APP.COMBINESAMPLES_LOCPU: If the CPU is lower than this value, audio samples are not combined. The default value is 60. To increase live streaming capacity, set this value to 1.

   • APP.COMBINESAMPLES_HICPU: If the CPU is higher than this value, audio samples are not combined. The default value is 80. To increase live streaming capacity, set this value to 1.

   • APP.COMBINESAMPLES_MAXSAMPLES: Combine this many samples into one message. The default value is 4. To increase live streaming capacity, set this value to 8.

3. Restart the server.

A high connection rate to the server can negatively impact the experience of users already connected to the server.

1. Locate the following code in the Server.xml configuration file:

   <Root> 
       <Server> 
           ... 
           <Protocol> 
               <RTMP> 
                   <Edge> 
                       <MaxConnectionRate>100</MaxConnectionRate>

   Element	Description	Impact
   MaxConnectionRate	The maximum number of incoming connections per second the server accepts, per listener. Listeners are defined in the HostPort element in the Adaptor.xml file. Each port the server is configured to listen on represents a listener. You can set a fractional maximum connection rate, such as 12.5. A value of 0 or -1 disables this feature. The value of this element is a global setting for all listeners. If the element is set to 10 connections per second, each listener has a limit of 10 connections per second. If there are three listeners and the MaxConnectionRate is set to 10, the server imposes a maximum total combined rate of 30 connections per second.	Connections requested at a rate above this value remain in the TCP/IP socket queue and are silently discarded by the operating system whenever the queue becomes too long.

2. Validate the XML and save the XML file.

3. Restart the server.

Sometimes users abandon their connections to an application. To reclaim these resources for new and active clients, the server can close the idle clients.

A client is active when it is sending (e.g., publishing) or receiving (e.g., subscribing to) data. Elements in the Server.xml, Vhost.xml, and Application.xml configuration files specify how often the server should check for idle clients. When a client has been idle longer than the maximum idle time (10 minutes, by default), the server sends a status message to the NetConnection object (the client) with the code property set to NetConnection.Connect.Idle followed by NetConnection.Connect.Closed. The server closes the client connection to the server and writes an x-status code of 432 in the access log. The server also writes a message such as “Client x has been idle for y seconds” in the core and event logs.

To close idle connections, enable the feature in the Server.xml file. Once you enable the feature in the Server.xml file, you can disable the feature for individual virtual hosts or individual applications in the Vhost.xml files and Application.xml files. The values defined in the Server.xml configuration file apply to all clients connected to the server, unless the values are defined in the Vhost.xml file (the Vhost.xml values override the Server.xml values). The values defined in the Application.xml file override the values defined in the Vhost.xml file.

In some scenarios, you might want to change how applications are assigned to server processes. When you start the server, you are starting a process called FMSMaster.exe (Windows) or fmsmaster (Linux). Application instances run in processes called FMSCore.exe (Windows) and fmscore (Linux). The master process is a monitor that starts core processes when necessary. There can be only one master process running at a time, but there can be many core processes running at a time.

You can configure how applications are assigned to server processes in the Process section of the Application.xml configuration file. Settings in an Application.xml file in a virtual host folder (for example, RootInstall/conf/_defaultRoot_/_defaultVHost_/Application.xml) apply to all the applications running in that virtual host. Settings in an Application.xml file in an application’s folder (for example, RootInstall/applications/myApp/Application.xml) apply only to that application. The following is the XML structure:

<Application> 
    <Process> 
        <Scope>vhost</Scope> 
        <Distribute numprocs="3"></Distribute> 
        <LifeTime> 
            <RollOver></RollOver> 
            <MaxCores></MaxCores> 
        </LifeTime> 
        <MaxFailures>2</MaxFailures> 
        <RecoveryTime>300</RecoveryTime> 
    </Process> 
    ... 
</Application>

Configure a process scope

 The Scope tag specifies at which level application instances are assigned to core processes. An application instance can run by itself in a process or it can run in a process with other instances. Enter one of the following values for the Scope element.

Value	Description
adaptor	All application instances in an adaptor run together in a process.
vhost	All application instances in a virtual host run together in a process. This is the default value.
app	All instances of a single application run together in a process.
inst	Each application instance runs in its own process. This provides the best application isolation and uses the most system resources. Running every instance in its own process can create many processes. You can set the Distribute numprocs attribute to a value greater than 1 to distribute instances across that number of processes.

Configure the number of core processes and how long each process runs

 Specify the number of core processes in the MaxCores tag (the maximum number of core processes that can exist concurrently) and the number of seconds that a core process can run in the RollOver tag. When a core process reaches the limit, any new connections roll over to a new core process.

The following diagram depicts the way in which the server rolls over processes. In the XML, the rollover time is set to 3600 seconds (1 hour), indicating that every hour a new process should start, and the maximum core processes value is set to 3, indicating that the maximum number of processes at any given time is 3:

<Process> 
    <Scope>app</Scope> 
    <LifeTime> 
        <RollOver>3600</RollOver> 
        <MaxCores>3</MaxCores> 
    </LifeTime> 
...

View full size graphic

A. Client connections B. Process 1 starts C. Process 2 starts D. Process 3 starts E. Process 4 starts; Process 1 ends, because the maximum core processes limit was reached

When each process starts, it accepts new connections until the next process starts: that is, when process 1 starts, it accepts new client connections to the application until process 2 starts; process 2 then accepts new client connections until process 3 starts; and so on.

Note that the duration of process 1 might or might not be the full duration specified by the rollover value, because rollover values are calibrated to the real clock time. The duration of process 1 is partially determined by the current time when process 1 starts. For example, as shown in the diagram, when process 1 starts, the current time is 12:20, so the duration of process 1 is only 40 minutes (because it is 40 minutes until the beginning of the hour in real time). The duration of the first process is determined by the clock time; subsequent processes have a duration equal to the specified rollover time.

To disable this feature, set RollOver to 0. This feature is disabled by default.

Note: If you have multiple VHosts with Process/Scope set to adaptor, you must set an identical RollOver value for each VHost.

In stateless applications, such as vod applications, old core processes continue to serve earlier connections. In this case, you can specify a value in the MaxCores tag to limit the maximum number of core processes that can run simultaneously. If the application is not stateless, the server ignores any value you assign to MaxCores and sets it to 1. This ensures that an application instance is not split across multiple processes, but clients are disconnected periodically. To disable this feature, set MaxCores to 0. This feature is disabled by default.

Note: An application is considered stateless if you configure it to distribute clients over multiple processes. To do this, set the Distribute numprocs attribute to a value greater than 1, then set the Distribute tag to clients or set the Scope tag to inst.