Запуск процессов apache сверх заданного числа при наличии свободных ресурсов

Правильно.

Грубо говоря, апач будет взаимодействовать с nginx, как с прокси - через TCP-соединение. Они вообще могут быть на разных серверах.

Эти действия имеет смысл измерять лишь усредненно, за какой-то промежуток. Да и вообще, такие измерения наглухо привязаны не только к конкретной ОС, но и к железу. Апач же - независимое от этого изделие.

Вот тут меня знания подводят. Разъясните, пожалуйста, на всём протяжении скачивания файла, под обслуживание этого клиента (который файл скачивает) будет занят только процесс nginx или процесс apache тоже будет в свою очередь занят обслуживанием этого процесса nginx на всём протяжении скачивания файла? Просто мне пока не понятен процесс скачки файлов больших в данном случае. В случае со страницами всё понятно, вроде: апач отдал страницу nginx'у и освободился, а nginx продолжает заниматься передачей этой страницы, которую он держит в ОЗУ, пользователю. А в случае с файлами статическими пользователь обратиться к nginx'у, тот обратиться к апачу, апач, выполнив необходимые действия (проверка существования файла, прав на доступ и т.п.), начнёт постепенно передавать файл nginx'у? Или он просто, грубо говоря, скажет nginx'у, что надо вернуть пользователю такие-то HTTP заголовки и начать передавать ему такой-то файл, и процесс апача освободится, а процесс nginx'а начнёт передавать большой файл клиенту?

Ну, можно же можно сделать так, что бы при установке такого модуля для апача надо было написать программу для конкретной ОС, которая бы возвращала в определённом формате данные о загруженности системы, к которой бы и обращался данный модуль апача.

Смысл использования nginx как акселератора – заставить его отдавать статику напрямую с диска, динамику на апач редиректя. В таком случае прирост производительности будет существенный.

Это никому не нужно =)

Но, если он, минуя апач, будет отдавать статику, то на различные запреты и др. настройки, касательно этого файла, указанные в конфигах apache он не будет обращать внимания.

Именно так. Ну для этого придется конечно руками делать все это в Nginx.

если ответ апача не помещается в буфер, то он пишется в файл и оттуда уже отдаётся клиенту

Если сам nginx не настроен на отдачу статики, то он получит файл от апача по HTTP и будет отдавать клиенту из своего буфера. А далее, как сказал Roxis:

Тоже "костыль", но на другом языке написанный. :)

Характеристики нагрузок в web подразумевают значительный запас мощности сервера для пиковых нагрузок. Ваше же предложение подразумевает ровно работающий недалеко от предела сервер, что в вебе нереально.

Как не совершенен этот мир...😒 Не у что нет готового решение, что бы апач просто выполнял все действия по обработке страниц и файлов, а затем передавал "лёгкому" процессу (тому же nginx'у, например) либо результат работы либо ссылку на файл в файловой системе, который надо передать?

Ведь, если настроить nginx в качестве только акселератора, при отдаче больших файлов, видимо, от такого решения будет только вред, а не польза, т.к. лишний раз надо будет скопировать файл перет отправкой конечному пользователю.

А если настроить nginx для отдачи статики, то возникает геморрой при синхронизации виртуальных хостов и т.п. между apache и nginx.

Возможно я неверно понимаю суть настройки апача, так что поправьте, если ошибаюсь.

Ведь в конфиге апача прописывается, помимо всего прочего, максимальное кол-во одновременно работающих дочерних процессов, которые обслуживают запросы пользователей. И именно с помощью этого параметра и регулируется дозволенное потребление ресурсов апачем. И этот параметр выставляется на глазок, исходя из ресурсов сервера и его прогнозируемой загруженности. А поскольку процессы апача далеко не одинаковые (в плане потребления оперативной памяти и ресурсов процессора) может возникнуть ситуация, что ресурсы для обработки запроса пользователя есть, но запрос пользователя при этом не может быть обработан из-за ограничения на кол-во процессов. А если разрешить слишком много одновременно существующих процессов, то появляется риск, что сервер "ляжет". Т.е. найти золотую середину практически невозможно и приходится постоянно её корректировать.

Единственным, на мой взгляд, решением данной проблемы является предоставление апачу оперативной (с точностью до секунды, как говорится) информации о загруженности сервера в данный момент времени. И, исходя из этой информации, он будет решать: запустить ли ещё один процесс для обработки запроса при этом не "положив" сервер или отказать пользователю в обработке его запроса из-за нехватки ресурсов в данный момент.

P.S.: всё это в основном относится к VPS хостингам, где ресурсов не так много и желательно использовать их максимально рационально.

Для этого существует таймаут соединения в браузерах.