%20tiene%20alg%C3%BAn%20l%C3%ADmite%20de%20ancho%20de%20banda%20predeterminado%3F.png)
Estoy ejecutando Apache en un servidor en la nube (servidor Windows 2008 R2 en VMware, 1 Gbps de BW http://95.110.164.61
). Estoy transmitiendo muchos DVB MPEG Transport Stream en vivo, precomprimidos en bucle (no flash) generados por VLC en el puerto 640xx y luego con proxy inverso por Apache en el puerto 80.
El firewall del servidor está abierto para VLC y Apache en todos los puertos.
Por encima de 1,5 Mbps la reproducción se ve afectada por un stop & go continuo. Tenga en cuenta que si solicita una transmisión generada por VLC directamente verá http://95.110.164.61:64087/mpg2_6.4
una transmisión correcta, mientras que si la solicita http://95.110.164.61/mpg2_6.4
no la verá.
Sé que Flash streaming Server usa Apache para transmitir en el puerto 80 (y funciona). No soy un experto en Apache, ¿alguien puede decirme si se requiere algún módulo "especial" para aumentar el ancho de banda?
Respuesta1
Apache no tiene ninguna limitación de velocidad ni de ancho de banda de forma predeterminada. De hecho, sólo los módulos externos proporcionan esta funcionalidad, por lo que habría tenido que hacer un esfuerzo especial para habilitarla.
De forma predeterminada, Apache utilizará todo el ancho de banda posible.
Respuesta2
Todavía Igino Manfre' sigue escribiendo (no lo olviden, soy un novato en Apache).
Quizás no debería describirse como límite de ancho de banda, pero el resultado final es el mismo: si Apache no está configurado correctamente, no puede enviar suficiente información a través de la web.
Esta actividad en Windows se realiza mediante módulos multiproceso de Apache (los únicos disponibles en Windows, oficialmente llamados Módulo de procesamiento múltiple pero a menudo llamados "Trabajadores") que en cualquier caso requieren ser configurados. Cuando Apache se ejecuta en Windows, solo encuentra dos procesos "httpd", uno secundario al otro. El proceso hijo activa todos los subprocesos requeridos por la conexión. En la documentación de Apache descubrí que se requiere una sección específica para cualquier sistema operativo que pueda copiarse desde extra\httpd-mpm.conf y pegarse en httpd.conf. La sección predeterminada de Windows contiene solo dos líneas dentro de la etiqueta "IfModule mpm_winnt_module" para administrar el subproceso múltiple.
ThreadsPerChild: número constante de subprocesos de trabajo en el proceso del servidor (establecido en 150)
MaxRequestsPerChild: número máximo de solicitudes que atiende un proceso de servidor (establecido 0, automático)
Pero en este caso, no es un problema de eficiencia del software (es decir, de subprocesamiento) sino probablemente de almacenamiento en búfer de la red. Encontré en la enorme documentación de Apache la existencia del parámetro SendBufferSize (que se agregará al httpd.conf). Aumenta el tamaño del búfer de envío TCP, útil para compensar una conexión de alta latencia con RTT de más de 100 ms (como en una conexión doméstica ADSL normal). De forma predeterminada o cuando está en 0, el servidor utilizará el sistema operativo predeterminado.
EnviarBufferSize 1000000
Decidí ponerlo en 1000000 (1 MB), lo que podría parecer un número grande, pero he visto el uso de estos valores altos.
¡BIEN FUNCIONA! Al abrir la transmisión con el reproductor VLC, ahora Apache transmite los 6,4 Mbps como lo hizo VLC. Significa que se ha eliminado el cuello de botella. Por el método científico, he probado que comentando este parámetro, el streaming vuelve a sufrir de stop and go.
En cualquier caso, para ver la transmisión correctamente necesitas tener un ancho de banda de conexión suficientemente mayor que el requerido para reproducir esa transmisión (digamos, al menos un 30%), por lo que para ver los 6,4 Mbps necesitas al menos 8 Mbps.
Espero que estas líneas ayuden a alguien más.
Otra advertencia: al introducir los vídeos en una página web y desear utilizar el complemento VLC, también es necesario configurar el parámetro de caché de red del complemento VLC, o la reproducción seguirá afectada por el stop and go. Parece que arreglar el network-cache=1000 (mseg), como está configurado por defecto en el reproductor VLC, es suficiente. La documentación, como siempre, nunca es suficiente.
Adiós Igino.