Попытка изложить ответы выше более точно (и исправить некоторые части) ...
мультиплексирование позволяет сократить накладные расходы на создание новых подключений к клиентам FCGI, эффективно переплетая фрагменты запросов
В отличие от keep-alive, он значительно сокращает количество новых подключений, особенно на серверах с высокой нагрузкой или при использовании микрообслуживания (много микро-запросов). Более того, это почти необходимо в случае балансировки между сетями (поэтому нельзя больше использовать unix-сокеты, и процесс создания соединения приобретает все больший приоритет).
и в то же время включение модели "keep-alive" для подключения
Хотя мультиплексирование не требуется для поддержания активности, но поддержание активности почти необходимо для мультиплексирования (в противном случае это не имело бы особого смысла).
Я обнаружил, что нет сервера, который реализует мультиплексирование FCGI
Существует несколько серверов, которые поддерживают мультиплексирование из коробки, но ...
Я видел уже несколько модулей других разработчиков и у меня есть собственный fcgi-модуль для nginx (как замена), который поддерживает мультиплексные запросы FastCGI.
Это может показать реальное увеличение производительности на практике, особенно если восходящие потоки подключены по сети.
Если кому-то это нужно, я постараюсь найти время и сделать его доступным на github и т. Д.
[ из ответа выше ] Мультиплексирование FastCGI, как правило, является плохой идеей, поскольку FastCGI не поддерживает управление потоком. Это означает: если сервер FastCGI отправляет данные, но http-клиент не может получить данные достаточно быстро, веб-сервер должен сохранить все эти данные, пока они не будут отправлены клиенту.
Это не правда. Обычно обработчики FastCGI полностью асинхронны, пул рабочих отделен от доставляющих рабочих и т. Д.
Таким образом, каждый блок получает идентификатор запроса, поэтому, если два или более работника из основной ветки разработки пишут в одно соединение одновременно, блоки, которые получит nginx, будут просто меньше. Это единственный минус.
Что касается «веб-сервер должен сохранить все эти данные», он делает это в любом случае (независимо от того, используется мультиплексирование или нет), потому что в противном случае можно получить нехватку памяти, если слишком много ожидающих данных доступно для ответа. Таким образом, либо бэкэнд должен производить меньше данных (или быть сорванным), либо веб-сервер должен получать их как можно скорее и передавать их клиенту или сохранять в какое-то временное хранилище (и, например, nginx делает это, если размер ожидающих данных превышает значения, сконфигурированные с помощью директив fastcgi_buffer_size и fastcgi_buffers ).
[ из ответа выше ] При использовании мультиплексирования веб-серверу необходимо прочитать все данные из бэкэнда fastcgi, даже если один из клиентов не получает данные достаточно быстро.
Также это неверно. Веб-сервер должен читать только один фрагмент ответа до конца, а хорошие рабочие пулы имеют «интеллектуальную» обработку, поэтому автоматически отправляет фрагменты на веб-сервер как можно скорее (то есть, если он становится доступным), поэтому если несколько провайдеров контента записывают в так называемые «отраженные» каналы одного и того же реального соединения, ожидающие пакеты будут отделены, и порции будут получены от nginx, как только будут получены данные ответа.
Таким образом, почти только пропускная способность соединения имеет решающее значение, и не имеет значения, насколько быстро клиенты будут получать данные.
И снова, мультиплексирование значительно экономит время на установление соединения, поэтому уменьшает количество ожидающих запросов, а также общее время выполнения запроса (скорость транзакции).