Хорошая идея, не подумал о ней :)
Но она требует лишние два системных вызова на выполнение запроса, а это долго 🤪 Они там боятся лишний раз указатель разыменовать.
Ну и мне не понятно, зачем при таком решении этому процессу быть частью nginx и чем это будет отличаться от access-лога и его парсера.---------- Добавлено 06.02.2014 в 20:55 ----------
Вам проблему обсудить или потроллить? :)
Странно, я тоже ее читал, и не увидел там ничего, кроме статистики.
Пожалуйста, перестаньте игнорировать различия понятия "веб-сервер" и "бекенд" (можно его еще назвать "сервер приложений") и опишите ситуацию, в которой Вам будет нужен список выполняющихся вебсервером запросов, но не подойдет список выполняющихся серверов приложений запросов.
Не за что, обращайтесь, если Вам понадобится мое решающее мнение еще по какому-либо вопросу :)
Не безущербно.
1) nginx выделяет общую память из мастер-процесса. Таким образом, с самого начала придется аллоцировать память под всю информацию о запросе. В качестве информации мы можем иметь URL (1кб) и по мелочи IP клиента+статус запроса. При стандартных настройках получается, что накладные расходы по памяти для этого процесса составят больше 10% всей используемой для обработки памяти
2) Так как требуется удаление из середины, должна использоваться структура данных "список" или "дерево". Реализация lock-free структур -- это достаточно трудоемкая задача, и в nginx они пока не реализованы. Использование мьютекса или спинлока для записи статистики в каждом запросе -- слишком дорого.
3) Скорее всего, данный модуль если и будет, то не будет собираться по-умолчанию из-за его низкой нужности, то есть использовать "просто так" его не получится -- придется ставить какую-то свою сборку nginx с этим модулем.
Модуль, который есть в nginx plus, тоже не показывает то, что Вы хотите. Он показывает числа (которые можно атомарно wait-free изменять, не заботясь о блокировках), описывающие статистику работы сервера за все время, а не текущий статус.
Кроме того, задача построения статуса является на 100% задачей бекенда, а не веб-сервера. В apache это реализовано из-за того, что он по сути является бекендом.
Почти все бекенды, которые Вы можете захотеть использовать с nginx, имеют поддержку статуса в том виде, в котором он нужен Вам.
А такой статус nginx'у и не нужен. С учетом возможности одновременной обработки сотен тысяч запросов.
Единственный относительно приличный форк, который я знаю -- это http://tengine.taobao.org/
Но статуса там нет.
Ситуация несколько сложнее, чем описал Himiko. У OpenVZ существует два вида лимитов на процессор -- cpuunits и cpulimit. Что они делают указано в документации на OpenVZ.
Если говорить кратко -- то cpuunits настраивает приоритет. Например, если есть vps с 100 cpuunits и vps с 200 cpuunits, то когда они начнут конкурировать за процессор, первый vps получит в два раза меньше процессорного времени, чем второй (то есть 33%/66%). cpulimit настраивает жесткий лимит. Если VPS ни с кем не конкурирует, но у него установлен лимит 20%, то система гарантирует, что в определенный (достаточно малый) промежуток времени vps не сможет занять больше 20% процессорного времени.
Как правило, пользуются первым лимитом, а не вторым, так как первый позволяет раздать пользователям простаивающий процессор и, в случае если нода не нагружена, получить более довольных пользователей. Когда пользуются первым лимитом, выделенными мегагерцами называют как раз выданное значение cpuunits.
К KVM-машине можно применить ограничение, аналогичное cpuunits в OpenVZ.
UPD: оказывается, можно применить и жесткое ограничение, как cpulimit.
На admin@, administrator@, postmaster@, webmaster@ или hostmaster@ Вашего домена.
Если у Вас домен .com/.net или другой с открытым whois, то можно отправить на административный или технический контакт домена.
Если хостинг уже есть, но почту заводить нет желания, то можно подтвердить путём размещения специального файла по http на Вашем домене.
Провайдеру достаточно тяжело предоставить Вам стандартный SSL, так как активация SSL для Вашего домена требует от Вас некоторых действий (например, переход по ссылке в проверочном письме). Существуют средства автоматизации, позволяющие получить сертификат в несколько кликов, но в России они почему-то пока не распространены. Будем улучшать ситуацию :)
Если хотите, можете заказать сертификат у нас. Нужно только заполнить всю необходимую информацию у нас на сайте, перейти по ссылке, которая будет отправлена на admin@ВашДомен.рф, после чего дать нам доступ к любому хостингу, где для Вас разрешен SSL, и мы установим сертификат.
РЕКЛАМА
https://www.domishko.ru/vdsservers/
Все, как Вы просите
Скажите, Вы троллите? :)
Они уже 10 лет не могут от постоянных бсодов избавиться или ntfs/x64 прикрутить, а Вы предлагаете ставить это клиентам на сервера.
Кроме того, клиентам на серверах как минимум еще IIS, ASP.net, MSSQL и прочее добро нужно, чего они точно в ближайшие 20 лет не смогут написать даже при выдаче им 1200000$ вместо 120000$.
Насколько я понимаю, sftp должен работать, а вот обычный ssh при этом отвалится
