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.

I'm running Apache on a server in cloud (Windows server 2008 R2 on VMware, 1 Gbps of BW, http://95.110.164.61 ). I'm streaming many live DVB MPEG Transport Stream, precompressed in loop, (not flash) generated by VLC on port 640xx and then reverse proxied by Apache on port 80.

The server's firewall is open for VLC and Apache on all ports.

Above 1.5 Mbps the reproduction is affected by continous stop & go. Please note that if you request a stream generated by VLC directly at http://95.110.164.61:64087/mpg2_6.4 you see a correct stream, while if you request http://95.110.164.61/mpg2_6.4 you do not.

I know that Flash streaming Server uses Apache to stream on port 80 (and it works). I'm not an expert with Apache, can anyone tell me if any "special" module is required to increase the bandwidth?

share|improve this question

2 Answers 2

Apache does not have any rate limiting or bandwidth limitations by default. In fact, only external modules provide this functionality, so you'd have had to make a special effort to enable it.

By default, Apache will use as much bandwidth as it can.

share|improve this answer

Still Igino Manfre' is writing (please do not forget, I'm an Apache newby).

Maybe it should not described as bandwidth limit, but the final result is the same: if Apache is not correctly configured it is unable to push enough information through the web.

This activity under Windows is done by Apache multithreading modules (the only available under Windows, officially called Multi Processing Module but often called "Workers") that in any case require to be configured. When Apache runs under windows you find only two processes "httpd", one child to the other. The child process activates all the required threads by the connection. On the Apache documentation I've found that it is required a section specific for any OS that can be copied from extra\httpd-mpm.conf and pasted into httpd.conf. The windows default section contains only two lines within the label "IfModule mpm_winnt_module" to manage the multithreading.

ThreadsPerChild: constant number of worker threads in the server process (set 150)

MaxRequestsPerChild: maximum number of requests a server process serves (set 0, auto)

But in this case, it is not a problem of software efficience (so of threading) but probably of network buffering. I've found on the huge documentation of Apache the existence of the SendBufferSize parameter (to be add to the httpd.conf). It increases the TCP send buffer size useful to compensate high latency connection with RTT more than 100ms (as in normal ADSL home connection). By default or when is to 0, the server will use the OS default.

SendBufferSize 1000000

I decided to put it at 1000000 (1 MB) that could sound a big number, but I've seen around the usage of these high values.

WELL IT WORKS! Opening the stream with VLC player, now Apache streams the 6.4 Mbps as was done by VLC. It means the bottleneck has been removed. By the scientific method, I've tested that commenting this parameter, the streaming suffers again of stop and go.

In any case to see the stream correctly you need to have a connection bandwidth sufficiently bigger than what required to play that stream (say, at least 30%), so to see the 6.4 Mbps you need at least of 8 Mbps.

I hope these lines will help someone else.

Another caveat: introducing the videos in a webpage and desiring to use the VLC plug-in, it is also required to configure the VLC plug-in network cache parameter, or the reproduction will still affected by stop and go. It seems that fixing the network-cache=1000 (msec), as set by default in the VLC player, it is enough. The documentation -- as usual -- is never enough.

Bye, Igino

share|improve this answer

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.