Bandwidth considerations

Conducting calculations in your bandwidth strategy document, such as those in the previous section, helps you identify important bandwidth considerations for your application. However, it's worth exploring two important considerations that are highlighted in this last many-to-many example.

Client connection speed

Your bandwidth strategy document should help you deliver the correct amount of information to each client. In the last many-to-many calculation example discussed, note that even though it was a relatively simple application with a relatively small video stream, each client received 900 Kbps of information and published 300 Kbps. This is a lot of bandwidth—in fact, too much if your user is on a dial-up modem or, in some cases, even on DSL. Users connecting to this application with connections less than 400 Kbps will most likely encounter pauses for rebuffering and suffer other poor-quality effects.

Here are two things to keep in mind concerning client connections:

• Save bandwidth for network overhead. A client's bandwidth will not only need to carry data from your application, it will also need to carry traffic for normal network overhead. Reserve about 20% of a client's bandwidth for overhead when calculating the amount of data to send to each client.
• Some connections do not have the same upload and download speed. If your application requires interaction from the client (e.g., sending webcam video), make sure your application takes their upload limitations into account.

You can find good online tools for testing upload and download connection speeds. One useful test is at the Broadband Tests and Tools page from BroadbandReports.com.

Application design matters

In the previous example, you estimated that you would be able to add 500 total simultaneous participants to one server (125 rooms with four people each). What if you were to change the design of the application and, instead of allowing four people to connect to one conference room, you allowed only two people to connect to a particular room? Or you only have one big conference room and everyone connects?

Example 2a: Many rooms, few people

In the scenario where you have many rooms but limit each room to only two participants, the server bandwidth drops to 1.2 Mbps per room:

1.2 Mbps = (2 × 2) × 300 Kbps

You can now accommodate 1000 total simultaneous participants across 500 rooms on one server. Note also that the required client bandwidth drops to 300 Kbps upstream and downstream, which opens up the app to more possible users. It's still not a good application for dial-up users, but most DSL users should now be able to use this application.

Example 2b: Many more people in a room

These examples illustrate that the design of the application plays a very important role in bandwidth utilization and, ultimately, in the user experience.

Where to go from here

By now you should have a good idea of how to calculate the server bandwidth requirements for your application. What if your estimates require the server to serve up 800 Mbps of audio/video? Is it realistic to push this much bandwidth on one physical server machine? Two servers? Three servers?

Besides knowing the server bandwidth requirements, you should also have the information you need to estimate the bandwidth utilization of your application and the appropriate Flash Media Server licenses you will need—and some ballpark information about when you can expect to start thinking about adding another server as your traffic grows.

The last but most important piece of advice is to be sure that you thoroughly test your application yourself. Ultimately the only way to know for sure how what type of server resources your application will take is to test it in real-world conditions.

Page 3 of 3

Previous Page