Есть ли у Apache 2.2 (Windows) ограничение пропускной способности по умолчанию?

Question

Я запускаю Apache на сервере в облаке (Windows Server 2008 R2 на VMware, 1 Гбит/с полосы пропускания http://95.110.164.61). Я транслирую множество потоков DVB MPEG Transport Stream в реальном времени, предварительно сжатых в цикле (не flash), сгенерированных VLC на порту 640xx, а затем обратно проксируемых Apache на порту 80.

Брандмауэр сервера открыт для VLC и Apache на всех портах.

Выше 1,5 Мбит/с воспроизведение страдает от постоянного stop & go. Обратите внимание, что если вы запрашиваете поток, сгенерированный VLC напрямую, http://95.110.164.61:64087/mpg2_6.4вы видите правильный поток, а если запрашиваете, http://95.110.164.61/mpg2_6.4то нет.

Я знаю, что Flash streaming Server использует Apache для потоковой передачи на порт 80 (и это работает). Я не эксперт по Apache, может кто-нибудь сказать, требуется ли какой-либо "специальный" модуль для увеличения пропускной способности?

Answer 1

Apache не имеет ограничений скорости или пропускной способности по умолчанию. Фактически, только внешние модули предоставляют эту функциональность, так что вам пришлось бы приложить особые усилия, чтобы включить ее.

По умолчанию Apache будет использовать максимально возможную пропускную способность.

Answer 2

Игино Манфре все еще пишет (пожалуйста, не забывайте, я новичок в Apache).

Возможно, это не следует называть ограничением пропускной способности, но конечный результат тот же: если Apache настроен неправильно, он не сможет передавать достаточно информации через Интернет.

Эта деятельность в Windows выполняется модулями многопоточности Apache (единственный доступный в Windows, официально называемый Multi Processing Module, но часто называемый «Workers»), который в любом случае требует настройки. Когда Apache работает в Windows, вы видите только два процесса «httpd», один дочерний по отношению к другому. Дочерний процесс активирует все требуемые потоки через соединение. В документации Apache я обнаружил, что требуется раздел, специфичный для любой ОС, который можно скопировать из extra\httpd-mpm.conf и вставить в httpd.conf. Раздел Windows по умолчанию содержит только две строки в метке «IfModule mpm_winnt_module» для управления многопоточностью.

ThreadsPerChild: постоянное количество рабочих потоков в процессе сервера (установлено 150)

MaxRequestsPerChild: максимальное количество запросов, обслуживаемых серверным процессом (установите 0, авто)

Но в этом случае это не проблема эффективности ПО (потоковости), а, вероятно, сетевой буферизации. Я нашел в огромной документации Apache существование параметра SendBufferSize (который нужно добавить в httpd.conf). Он увеличивает размер буфера отправки TCP, что полезно для компенсации соединения с высокой задержкой при RTT более 100 мс (как в обычном домашнем соединении ADSL). По умолчанию или когда он равен 0, сервер будет использовать значение ОС по умолчанию.

SendBufferSize 1000000

Я решил установить значение 1000000 (1 МБ), что может показаться большим числом, но я видел, как используются такие высокие значения.

НУ РАБОТАЕТ! Открываю поток с помощью VLC player, теперь Apache транслирует 6.4 Мбит/с, как это делал VLC. Это означает, что узкое место было устранено. Научным методом я проверил, что комментируя этот параметр, поток снова страдает от остановок и переходов.

В любом случае, чтобы правильно увидеть поток, вам необходимо иметь пропускную способность соединения, существенно превышающую ту, которая требуется для воспроизведения этого потока (скажем, не менее 30%), так что для просмотра 6,4 Мбит/с вам потребуется не менее 8 Мбит/с.

Надеюсь, эти строки помогут кому-то еще.

Еще одно предостережение: при размещении видео на веб-странице и желании использовать плагин VLC также необходимо настроить параметр сетевого кэша плагина VLC, иначе воспроизведение все равно будет зависеть от остановки и перехода. Кажется, что исправления network-cache=1000 (мсек), как установлено по умолчанию в проигрывателе VLC, достаточно. Документации — как обычно — никогда не бывает достаточно.

Пока, Игино.