Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

A quick question. How many copies of the same movie are kept in a video server (a video streaming server)? Suppose a particular video is at max requested by 1000 users at the same instant of time, how many copies would be sufficient so that parallel streams can be provided to each user? Ideally 1 copy would solve the purpose, but what is the optimum number keeping the bandwidth and simultaneous access in mind?

share|improve this question

migrated from stackoverflow.com Mar 21 '10 at 9:20

This question came from our site for professional and enthusiast programmers.

3  
Probably belongs on ServerFault. –  Nathan Osman Mar 19 '10 at 21:30
add comment

4 Answers

The answer depends on the implementation of the streaming server. If it is threaded, than it should maintain a single memory buffer for that file. Howerver, if the file is very large (an hour of video can use more than 1 GB of memory), than the server may need to manage the portions of the file that are in memory appropriately. One approach is to memory-map the files (however, this may fail if the total size of the video is too large). Many video filetypes provide enough information to know which parts of the video to load to send a particular set of frames to the client.

If you were streaming 1Mbps video; with 1000 clients you are sending out 1Gbps concurrently to clients (not including overheads and variable spikes). You would need a 10Mbps upstream bandwidth from the server for this to work. Otherwise, you'll need to split it across servers.

share|improve this answer
    
if your OS's cache system is so bad that you're better mmap()ing a sequential-access file like video, you're using the wrong OS –  Javier Mar 21 '10 at 1:33
add comment

You shouldn't need more than one copy, as if that copy is being requested by 1000 simultaneous users, it would be in RAM already.

share|improve this answer
    
I agree. The video would be loaded in memory. The server would need some technique to serve the 1000 users. Probably, it will open 1000 connections to serve each user. But won't it slow down the access? What is the optimum approach, should there be 1000/k separate servers? If yes, should they access the video from the same location or should copies of videos be kept in the storage? –  Trilok Mar 19 '10 at 21:36
add comment

Typically, a web server would only have one copy of the file and load it into memory as requested - but I don't see any web server being so poorly written as to load 1000 copies of the file into memory.

By the way, 1000 simultaneous requests is a bit much for one server...

Maybe you want to set up a load-balancing scheme with multiple servers?

share|improve this answer
    
Thanks for the answer. Okay, if I try to balance the load with multiple (1000/constant) servers, should those servers access the video into their memories from the same location from the storage? Is it advisable to keep a few copies so that the multiple servers load them simultaneously from different locations? or even now, I copy is enough? –  Trilok Mar 19 '10 at 21:38
add comment

More copies would just make the problems worse in most cases. If you had multiple drives, you might get some benefit in having a copy of very popular movies on each drive. That would reduce the need for seeks if you were read the same file/stream in different places at the same time.

But having multiple copies on a single drive would just make the size of the seeks larger if you were reading from more than one version of the file at a time. If the movies are stored in RAM or SSD, then seeks aren't an issue, but space is, so you would want only a single copy to maximize the utilization of RAM or SSD space.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.