Respond to Demand

Expansion Planning

In most cases, EchoSystem deployments grow within one or two semesters, responding to demand from faculty and students. Deployment Planning and Initial Server Deployment explain EchoSystem design and architecture and assume demand for growth. This section discusses common reasons for system growth and considerations when responding to a demand for growth.

Capture or Venue Expansion

The most common growth scenario after initial deployment is capture expansion. Capture expansion may take place within an existing venue (classroom or auditorium) or into new venues. It is also quite common for institutions to plan for EchoSystem capture in new buildings as they become operational. Additionally, growth may occur by additional faculty requesting Personal Capture licenses.

Growing EchoSystem capture beyond the initial deployment must include planning for additional media processors and storage. For example, your initial deployment may consist of five capture appliances capturing 15 hours per day. Next term you will double capture volume in those venues to 30 hours per day and add an additional five venues at 15 hours per day. In this case, you will certainly need at least one additional media processor to keep up with the increased volume and expected turnaround time. You will also need to add storage capacity as the additional capture hours will increase the storage requirements.

As you expand, you may also require additional network bandwidth to handle the concurrent media file transfers from the capture devices. Consider installing additional network interfaces in the EchoSystem Server (ESS) computer and employing network teaming, or moving to a dedicated file transfer server.

In most cases increased capture results in increased student views.

Student Viewing

Increasing concurrent student view capacity is primarily a function of network bandwidth and, secondarily, a function of delivery server load. In other words, you will most likely reach network bandwidth limitations before server capacity limitations. Network bandwidth requirements are higher when supporting concurrent EchoPlayer views. This is due to the consistent bandwidth usage by the EchoPlayer (inherent in media streaming). By contrast, media file download, such as vodcast and podcast file download, consumes a fair amount of bandwidth for a short time, until the file is fully downloaded.

Bandwidth needs can be calculated by assuming the average network bandwidth scenario per student and calculating how many concurrent views the network interface will support. The average bandwidth requirement for the EchoPlayer is about 400 kbps. When concurrent student views near the amount of bandwidth available to the network interface(s) on the ESS computer, consider installing additional network interfaces and employing network teaming. You could also move to a dedicated web and streaming server.

If you are primarily providing podcast media for student review, network bandwidth may not be a concern during early growth. If it does cause concern, consider additional network interfaces in the ESS computer.

Server capacity can be determined using native operating system tools and best practices to measure CPU, RAM and disk I/O usage at peak usage times. When server capacity nears the maximum acceptable limit, plan on moving to a dedicated web and streaming server with the capacity to accommodate for continued growth.

You should also plan on using dedicated, load-balanced web and streaming servers when student demand is such that you must support thousands of concurrent connections.

Turnaround Time

Another possible response as initial deployment takes off may be the demand to decrease media availability time. Such demands immediately require additional media processors and may also require increased network bandwidth.

Alternatively, you can also employ a less secure file transfer method by changing to the "SFTP w/o Encryption" option in the ESS configuration or to a standard FTP service. These options increase file transfer time from capture appliances to the ESS by a factor of 10.

Redundancy and High Availability

Redundancy and high availability may be imperative. In these cases, all supporting application services should be moved to external systems, each with its own support for redundancy. ESS redundancy should be discussed with your Echo360 engineer.