Maintaining video website performance

Question

I am setting up a online video playing web site (like Youtube). My technical challenge is to serve a lot of hits and still maintain performance.

My current solution is to set up several back-end servers, having each server cache a part of the video which could save the time to read the video file from disk I/O.

Another front-end server will hash the request video ID to find out which server the video resides on, and then ask the client browser to redirect to the specific server.

My solution is simple, and I want to know whether anyone else have any better ideas or any technical considerations for my solution?

---

Please note: I want to set up the site to work locally (and not rely on providers like Alakami) as the content is for local students from my school. This will essentially be an 'intranet' solution.

Answer 1

Are you hosting this on Windows in IIS7? if so they have a module for IIS to do throttling on the video's so it is not streamed faster then the user can actually watch it.

Answer 2

One solution for very high performance is to use a data distribution service like Akamai. They offer server space all over the world and they have solved the performance issue already. Also, since they have data centers all over the world, your data doesn't have to travel very far which is good for the Internet and for you (since Akamai can charge lower fees for the same amount of data).

Answer 3

someone posted this link on Youtube scaling to me recently might be useful / relevant.

http://video.google.com/videoplay?docid=-6304964351441328559

Answer 4

Your solution will not perform well when all users request the same video. A better solution is to have all videos available on all servers and use a load balancing server to redirect the current request to the server which has the lowest number of feeds open.

Note that storage back ends (RAID arrays, SAN) can deliver data at a very high rate, so you often can get away with one storage system for several video servers (i.e. one storage system per N video servers and 1 load balancer (or two if you want failover)).

A good solution here is to have a "redirect" command in the protocol:

1. Client asks load balancer (LB) for video
2. LB tells client which video server (VS) to use. This is a simple "find VS with the lowest amount of open feeds."
3. Client connects directly to VS (to avoid all overhead)
4. VS tells LB the current amount of open feeds (don't use an incremental approach here to avoid synchronization issues)
5. VS begins streaming the data to the client
6. When a client disconnects, VS tells LB of the new number of feeds

[EDIT] The main reason to get the clients to connect directly to the video servers is network throughput. If all VS send their data to the LB who passes it on to the clients, you are limiting yourself to the speed of the single (or dual) network card of the LB. If you have 5 VS, you can get five times the throughput when connecting directly. Also, you can easily scale your system when more users hammer it by simply adding another video server, plugging it into the backbone and adding one entry to the list on the LB.

Answer 5

Try Amazon's CloudFront (a CDN) if your users are distributed all over the world. If your users are localized (US/Europe), you can use S3.

Additionally, you could also try using Nginx (a web server) which is extremely efficient at serving large files.

This way, you don't have to deal with un-necessary architectural complexity within your application.