We have an “intranet” web site (called SheaTV) in our company where we centralize all of our media assets (videos, podcasts, training on demand videos, etc.). From there, our users can easily find what they want to watch (or listen to) by searching through a variety of subjects.

SheaTV has become very popular this year within our company. More and more people (we have over 1500 employees) go to SheaTV everyday to watch a video about our company, learn how to use one of our softwares (by watching a training on demand video) or to listen to an internal podcast.

Of course every rose has a thorn, and the big “thorn” is the issue of bandwidth usage. That is, the more people are watching our videos in SheaTV (rose), the more bandwidth we end up using (thorn) which affect other applications, websites and other resources which also use (and depend heavily on) the network bandwidth.

So what to do?

DEFINE THE PROBLEM:
We have a popular video site that uses a lot of our WAN bandwidth because we have users in different divisions throughout the U.S. watching these videos. SheaTV is located in one location (centralized) and all the videos are served up through that one location to all of our users.

COME UP WITH A SOLUTION:
Leave the main site in the central server (website code). Remove all assets (videos, podcasts, training on demand videos, etc) from that main web server and place them into “asset servers” located locally in each division (we have about 12 divisions). Use current file servers that are already located in those divisions to “serve up” these assets.

IMPLEMENTATION:

1. Remove all assets (videos, podcasts, training on demand videos) from the web server and place them in their own “asset server”. This process required changing code in our site.
2. Install new servers (or use current file servers) in each division with IIS (Microsoft’s web server) and store all of the media assets in those servers (same assets for each server)
3. Create a virtual directory in all the IIS asset servers called “/media” and store all the assets within that directory (the directory structure has to be the same in all the asset servers.)
4. Write a script that will “duplicate” the assets from one asset server to another. For example, our main asset server is called “assets_corp”. I drop the media there and that server starts the replication process of that asset to all the other servers in the network. (It’s automatic and done once a night when the WAN traffic is low). So I don’t have to copy the same video or podcast to12 different servers.
5. Create a database (in MS SQL) with IP ranges for each division and what server it should get the assets from. Our database holds the location of the division, the IP range and also what the asset server name is.
6. Change the code in SheaTV (ColdFusion) to get the correct asset server (the closest in location) for the user browsing the site.
7. The code works the following way when the user browses to SheaTV:
   • Get local IP of user.
   • Do a lookup against the database for that IP (we store ranges of IP, not actual IPs) (see #5 above)
   • Get server to go get asset from based on that IP.
   • Go get asset from that server (locally).

OUTCOME:
Huge improvement in download speeds (over 200% improvement) because all the files are now being served up by the local file server where the user is located (not the main website server) and the WAN traffic has been cut tremendously since all files are pulled from their local LAN, not the WAN.

That’s it. Of course, implementation took a bit longer then it seems from above, but the concept is really easy.

You can actually use this type of system for any kind of file you want to serve up to the user, it does not have to be just for videos. You can use this to serve up PDFs, images, or anything else you can think of.

One note of clarification, this system is set up for an internal network (behind the corporate firewall) since you should be able to get IP ranges and locations for users from your network team, this system would not work if your site is live on the Internet (public).  You would have to come up with a different solution for that.

Until the next blog!

Cheers!

- Marcelo Lewin

The Digital Media Dude

http://www.thedigitalmediadude.com/

http://www.marcelolewinphotography.com/