Deploying edge servers

Workflow for deploying edge servers


Adobe Media Server Standard cannot be configured as an edge server.

By default, the server runs as an origin server. To run the server as an edge server, you must configure an XML file. Typically you would run Adobe Media Server Professional as an origin server on one computer and run Adobe Media Server Professional as an edge server on another computer.

Install Adobe Media Server Professional and verify the installation on each computer.

Deploy all edge and origin servers on computers that meet the minimum system requirements. For information about installing and verifying installation, see the Installation Guide.


For cross-platform compatibility, use lowercase names for all folders and applications.

Configure an edge server and restart.

On the edge server, edit the Vhost.xml file of the virtual host you want to run as an edge server.

Verify that the edge server can communicate with the origin server.

The easiest way to verify is to create an explicit connection. Create a SWF file with an explicit connection to the edge server and run the vod or live service.

If you’re installing multiple edge servers, copy the Vhost.xml file to the same directory on each edge server.

Verify that each edge server can communicate with the origin server.

Place the origin server and those edge servers nearest to it on the same subnet.

If you’re deploying more than one edge server, configure a load balancer.

Place the load balancer between the clients and the edges. Configure the load balancer to access the pool of edge servers in round-robin mode and to monitor over TCP port 1935. Use the virtual IP (VIP) address of the pool as the IP address in the RouteEntry element of each edge server’s Vhost.xml file. For detailed information on how to configure the RouteEntry element, see the comments in the RouteEntry element of the default Vhost.xml file, or see RouteEntry.

Configure edge servers

To configure the server to run as an edge server, edit the Vhost.xml configuration file of the virtual host you want to run as an edge server. The Vhost.xml file defines how the edge server connects clients to the origin server.


You can also configure some virtual hosts to run applications locally (as origins), while others run applications remotely (as edges); this is called mixed mode or hybrid mode.

Configure a virtual host to run as an edge server

  1. Open the Vhost.xml file of the virtual host you want to configure and locate the following code (comments have been removed):

             <CacheDir enabled="false" useAppName="true"></CacheDir> 
             <RouteTable protocol=""> 

    The default VHost.xml file is located in the RootInstall/conf/_defaultRoot_/_defaultVHost_ directory.

  2. Edit the following XML elements, as needed.






    Enter local to configure the server to run as an origin server. Enter remote to configure the server to run as an edge server.



    A Boolean value specifying whether the edge server connection is implicit (true) or explicit (false). The default value is false.



    Enables or disables the caching of streams to disk, in addition to caching in memory, on an edge server and allows you to specify the cache location. There are two attributes: enabled and useAppName.

    To enable caching, set the enabled attribute to "true". When enabled, the server places streams in the RootInstall/cache/appName directory by default. Use the useAppName attribute to specify whether to use the application name as the name of the cache for the application.

    Vod applications get significant performance gains when caching is enabled.



    Specifies the local IP address to which to bind a proxy's outgoing connection (the proxy’s loopback address). This element allows the administrator to control network traffic by isolating incoming and outgoing traffic to separate network interfaces.


    Optional; create a routing table when it is not necessary or desirable for application developers to see the origin server URL or when you want to use implicit connections.

    Specifies, in each RouteEntry element, how to route connections from the origin to the edge. There is one attribute, protocol, that indicates the protocol of the outgoing connection. Set this attribute to either "rtmp" or "rtmps".

    To override the RouteTable protocol for a specific RouteEntry element, add a protocol attribute to the RouteEntry element you want to change.



    Each RouteEntry element maps a host/port pair to a different host/port pair. In the following example, connections to host1:port1 are routed to host2:port2:


    Typically, host1:port1 is your edge server and host2:port2 is your origin server. The following example routes connections destined for host "edge" on port 1935 to host "origin" on port 80:


    You can specify a wildcard character (*) for any host or port. The following example routes connections destined for any host on any port to host "origin" on port 1935:


    You can also specify a wildcard for the host/port to which connections are being routed. The following example routes connections destined for any host on any port to the same host on port 80:


    To reject connections, you can specify that a host/port combination be routed to null:


    The RouteEntry element has a protocol attribute. This attribute overrides the RouteTable protocol for a specific RouteEntry element. For example, RouteTable may have one RouteEntry element that specifies an encrypted outgoing RTMPS connection and another RouteEntry tag that specifies the regular RTMP connection. If a protocol is not specified, the outgoing connection uses the same protocol as the incoming connection.

  3. Validate the XML and save the Vhost.xml file.

  4. Restart the server.

Set up caching on edge servers

Streams that are played via an edge server can optionally be cached on that edge server’s hard drive to avoid extra network traffic back to the origin. Edge servers manage their disk caches automatically using a least-recently-used (LRU) scheme.

Edge servers group the cached files on disk into buckets; the files within each bucket are not ordered, but the buckets themselves are ordered by LRU. When an edge server needs to free up disk space, it deletes the entire contents of the least-recently-used buckets. When a file is added, it gets put in the "newest" bucket, and likewise when an existing file is accessed, it is moved to the newest bucket. This maintains the LRU ordering.

A disk cache is divided up into N buckets, but since all newly accessed content goes into the newest bucket, only the newest bucket actually grows in size. Once that bucket reaches K/N bytes, where K is the maximum size of the disk cache, the server triggers a rollover. A rollover means the server deletes the oldest bucket, and creates a new bucket where new content will go.

For example:

  1. Start with an empty disk cache, configured to have 8 buckets and max size of 80 GB.

  2. All content goes into bucket "00" until it grows to 10 GB.

  3. New bucket "01" is created. All content now goes into this bucket. In addition, content accessed from bucket "00" may be moved to bucket "01".

  4. When bucket "01" reaches 10 GB, the server creates bucket "02", and so on.

  5. Repeat until there are 8 buckets, "00" through "07".

  6. When bucket "07" reaches 10 GB, the server creates bucket "08", and also deletes bucket "00" and all the content it contains.

The deletion is only triggered by the size of the "new" bucket, not the total size of the disk. Because content can be moved from one of the older buckets into the newest bucket, the older buckets do not remain at their maximum size of N/K bytes, and thus the total size of the disk will be less than its max K when the server starts deleting old buckets.

You set up caching on an edge server in the CacheDir element of the Vhost.xml file. The following table describes the subelements that you use to set up caching:




Specifies the maximum allowed size of the disk cache, in gigabytes. The server does LRU (least recently used) cleanup of the cache to keep it under the maximum size. The default value is 32 gigabytes. A value of 0 disables the disk cache. A value of -1 specifies no maximum.


Specifies the number of buckets to divide the cache into. The aggregate cache size is defined by MaxSize. Can be any value from 2 to 128; the default value is 8. More buckets mean that a smaller portion of the disk content will be deleted at any one time, but also that files will need to be moved to new buckets more often, which results in more disk activity and lower performance.You can define the number of buckets that contain contents that can be moved with NumBucketsAtRisk.


Specifies the number of buckets considered to be "at risk" of deletion. Can be any value from 0 to NumBuckets - 1; the default is NumBuckets/2. To avoid moving files too frequently at the expense of disk performance, only segments that are in the oldest NumBucketsAtRisk buckets will be moved to the newest bucket when accessed.

A value of 0 means that segments, once pulled from the origin, are never moved to a newer bucket, effectively turning the cache into a LRU cache. The default value of NumBuckets/2 means that only segments in the "older half" of content will be moved. Segments in the "newer half" of content are more likely to be accessed again before they are deleted, thus making it less important to move them.

Connect to an edge server

There are two types of edge server connections: explicit and implicit (also called anonymous).

An explicit edge server prefixes its address to the origin server’s URL in the client NetConnection.connect() call. For example, for applications running on, instead of clients connecting to an application with a connection string such as rtmp://, clients are directed through the edge, which prefixes its protocol and hostname to the origin URL, as in the following:


An implicit edge server does not change or modify the origin server’s URL in the client NetConnection.connect() call. The identity (the IP address and port number) of the implicit edge is hidden from the application developer.

Create an explicit connection

  1. Use the following syntax in a client-side NetConnection.connect() call to make an explicit connection to an edge server:


    A question mark (?) separates the edge’s prefix from the main URL. The prefix contains only the protocol, hostname, and optionally the port number. The prefix must always end with a trailing slash.

Create an implicit connection

  1. In the Vhost.xml configuration file, set the Proxy/Anonymous element to true.


    Restart the server after changing the Vhost.xml file.

  2. In the Vhost.xml file, create a routing table in the RouteTable element; for more information, see the comments about RouteEntry tags in the Vhost.xml file installed with Adobe Media Server.

  3. Use the following syntax in a client-side NetConnection.connect() call to make an implicit connection to an edge server:


Connect edge servers in a chain

  1. You can chain together any number of edges when you make connections to the origin server. Use the following syntax to chain two explicit edges to direct connection requests to the origin server:


    As the connection moves through each edge in the chain, the server consumes the first token in the string. For example, after making the connection to edge1, the connection string changes to:


    You can specify the RTMPT protocol only for the edges, not for the origin.


    When you use URL decoration to chain edges, Flash Player 7 and earlier versions may have problems with shared objects because of the embedded question mark (?) character in the URL. Call the following function to encode or escape the question marks from the URL before passing the URL to the shared object:

     function escapeURI(uri) { 
         index = uri.indexOf('?'); 
         if (index == -1) return uri; 
         prefix = uri.substring(0, index); 
         uri = uri.substring(index); 
         return prefix += escape(uri); 
Adobe logo

Sign in to your account