Выглядит, как чёрный пиар.
Dmitry Danilenk, скажите, пожалуйста, когда, примерно, планируется восстановление нормальной работы VPS серверов?
Так же очень интересно, почему у Вашей организации такой маленький резерв мощностей, если электроэнегрии всего лишь на 2 часа хватило? Планируется в будущем, увеличение резервных мощностей электроэнергии?
Вы видимо недопоняли моего сообщения. Да и по-любому, тайм аут в браузерах по умолчанию, не меньше минуты выставляется, если мне память не изменяет.
Это-то здесь при чём???
P.S.: когда я говорил про то, что процессы апача слишком разные в плане потребления ресурсов, я прежде всего имел ввиду ситуацию, когда на сервере лежит несколько сайтов (точнее скриптов), довольно разнородных по своей сущности (опять же в плане потребления ресурсов).
Ну не совсем :) Ваше решение меня смущает тем, что после внесения поправок в конфиг файл апача, который инклудится, надо перезапускать родительский процесс апача. Думаю, это не слишком хорошо на производительности скажется. Хотя, всё же, если подумать, то перезапускать надо будет не каждую секунду всё таки, а наверно, раз в минуту оптимально будет (тут у меня опять нехватка опыта сказывается😒). Но по-любому, Ваше решение на текущий момент единственно осуществимое для меня, за что Вам спасибо :)
Как не совершенен этот мир...😒 Не у что нет готового решение, что бы апач просто выполнял все действия по обработке страниц и файлов, а затем передавал "лёгкому" процессу (тому же nginx'у, например) либо результат работы либо ссылку на файл в файловой системе, который надо передать?
Ведь, если настроить nginx в качестве только акселератора, при отдаче больших файлов, видимо, от такого решения будет только вред, а не польза, т.к. лишний раз надо будет скопировать файл перет отправкой конечному пользователю.
А если настроить nginx для отдачи статики, то возникает геморрой при синхронизации виртуальных хостов и т.п. между apache и nginx.
Возможно я неверно понимаю суть настройки апача, так что поправьте, если ошибаюсь.
Ведь в конфиге апача прописывается, помимо всего прочего, максимальное кол-во одновременно работающих дочерних процессов, которые обслуживают запросы пользователей. И именно с помощью этого параметра и регулируется дозволенное потребление ресурсов апачем. И этот параметр выставляется на глазок, исходя из ресурсов сервера и его прогнозируемой загруженности. А поскольку процессы апача далеко не одинаковые (в плане потребления оперативной памяти и ресурсов процессора) может возникнуть ситуация, что ресурсы для обработки запроса пользователя есть, но запрос пользователя при этом не может быть обработан из-за ограничения на кол-во процессов. А если разрешить слишком много одновременно существующих процессов, то появляется риск, что сервер "ляжет". Т.е. найти золотую середину практически невозможно и приходится постоянно её корректировать.
Единственным, на мой взгляд, решением данной проблемы является предоставление апачу оперативной (с точностью до секунды, как говорится) информации о загруженности сервера в данный момент времени. И, исходя из этой информации, он будет решать: запустить ли ещё один процесс для обработки запроса при этом не "положив" сервер или отказать пользователю в обработке его запроса из-за нехватки ресурсов в данный момент.
P.S.: всё это в основном относится к VPS хостингам, где ресурсов не так много и желательно использовать их максимально рационально.
Но, если он, минуя апач, будет отдавать статику, то на различные запреты и др. настройки, касательно этого файла, указанные в конфигах apache он не будет обращать внимания.
Вот тут меня знания подводят. Разъясните, пожалуйста, на всём протяжении скачивания файла, под обслуживание этого клиента (который файл скачивает) будет занят только процесс nginx или процесс apache тоже будет в свою очередь занят обслуживанием этого процесса nginx на всём протяжении скачивания файла? Просто мне пока не понятен процесс скачки файлов больших в данном случае. В случае со страницами всё понятно, вроде: апач отдал страницу nginx'у и освободился, а nginx продолжает заниматься передачей этой страницы, которую он держит в ОЗУ, пользователю. А в случае с файлами статическими пользователь обратиться к nginx'у, тот обратиться к апачу, апач, выполнив необходимые действия (проверка существования файла, прав на доступ и т.п.), начнёт постепенно передавать файл nginx'у? Или он просто, грубо говоря, скажет nginx'у, что надо вернуть пользователю такие-то HTTP заголовки и начать передавать ему такой-то файл, и процесс апача освободится, а процесс nginx'а начнёт передавать большой файл клиенту?
Ну, можно же можно сделать так, что бы при установке такого модуля для апача надо было написать программу для конкретной ОС, которая бы возвращала в определённом формате данные о загруженности системы, к которой бы и обращался данный модуль апача.
Скажите, правильно ли я понимаю, что в данном случае (если только как акселератор) поведение будет следующее:
пользователь запрашивает страницу у nginx, который будет обращаться за этой страницей к апачу. Апач выдаст эту страницу, nginx будет держать её у себя в оперативной памяти и отдавать пользователю. Так? Т.е. выгода будет, если у пользователя медленный канал и для него будет отведён процесс nginx, который жрёт намного меньше ресурсов, чем апач.
А как будут отдаваться в этом случае большие файлы (в несколько десятков мегабайт, например)? Как я понимаю, когда пользователь запрашивает по HTTP файл у апача, то процесс апача порционно считывает данные из файла и передаёт их в поток, открытый с пользователем. А, если в качества только акселератора будет nginx, то как он себя поведёт в данном случает? Т.е. если пользователь обратиться к nginx за большим файлом, то тот в свою очередь обратиться к апачу. И как будет отдаваться большой файл в данном случае? Будет как-то перекидываться поток считывания файла от апача к nginx'у? Или как?
P.S.: прошу сильно не пинать, я только недавно начал вникать в эту тему. :)
Костыль получается :) Всё же хочется сделать, что бы проверка осуществлялась именно при порождении дочерних процессов. Так по идее, информация о загруженности системы будет получаться настолько оперативно, насколько это возможно и с меньшими затратами.
Вообщем, как я понял готового решения нет... что ж, придётся отложить до лучших времён... :(
