хороший форк nginx'а

vapetrov, очень просто. Так - удобней и правильнее. Каждое приложение должно выполнять свою функцию.

Абсолютному большинству это не нужно. А кому нужно - могут заморочиться с установкой сторонних модулей, либо позволить себе разориться на платную версию. Тут уже зависит от того насколько это нужно (:

Не за что, обращайтесь, если Вам понадобится мое решающее мнение еще по какому-либо вопросу :)

Не безущербно.

1) nginx выделяет общую память из мастер-процесса. Таким образом, с самого начала придется аллоцировать память под всю информацию о запросе. В качестве информации мы можем иметь URL (1кб) и по мелочи IP клиента+статус запроса. При стандартных настройках получается, что накладные расходы по памяти для этого процесса составят больше 10% всей используемой для обработки памяти

2) Так как требуется удаление из середины, должна использоваться структура данных "список" или "дерево". Реализация lock-free структур -- это достаточно трудоемкая задача, и в nginx они пока не реализованы. Использование мьютекса или спинлока для записи статистики в каждом запросе -- слишком дорого.

3) Скорее всего, данный модуль если и будет, то не будет собираться по-умолчанию из-за его низкой нужности, то есть использовать "просто так" его не получится -- придется ставить какую-то свою сборку nginx с этим модулем.

Модуль, который есть в nginx plus, тоже не показывает то, что Вы хотите. Он показывает числа (которые можно атомарно wait-free изменять, не заботясь о блокировках), описывающие статистику работы сервера за все время, а не текущий статус.

Кроме того, задача построения статуса является на 100% задачей бекенда, а не веб-сервера. В apache это реализовано из-за того, что он по сути является бекендом.

Почти все бекенды, которые Вы можете захотеть использовать с nginx, имеют поддержку статуса в том виде, в котором он нужен Вам.

Зачем выделять общую память для статистики? Статистику можно отправлять в отдельный процесс, асинхронно через pipe/socket, т.е. сначала в воркере писать в локальный буфер, а потом этот буфер при заполнении или раз в пару секунд отправлять в отдельный процесс, а не будет успевать - не отправлять. Хотя идеи с lock-free алгоритмами - это вполне в духе nginx'а: написать гадкий сложнючий код, а потом годами ловить баги и уязвимости. Да и в духе наших программеров в целом.

Увольте.

К чему эти разглагольствования? stub_status, например, по умолчанию не компилится и никого это не напрягает.

Спасибо, но я читал документацию и имею представление, что он показывает, не перетруждайте свой телепатический аппарат.

nginx таки да, вебсервер, а не просто какой-то проксик, чтобы его в чистые фронтенды записывать.

Статус платного nginx'а достаточно информативен и настраиваемый. И, как я уже говорил, достаточно полезный, чтобы быть заманухой для покупки.

Огорчает то, что разработчики nginx'а уже очень давно саботировали добавление даже такого не слишком важного модуля, как статус. Явно с прицелом на будущую коммерциализацию.

Так что добавление новых фич в бесплатную версию, сдается, под большим вопросом. Несмотря на все уверения.

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

watch tail access.log

и внимательно смотри :)

Ну и молодцы разработчики. Я их поддерживаю в этом направлении.

Хорошая идея, не подумал о ней :)

Но она требует лишние два системных вызова на выполнение запроса, а это долго 🤪 Они там боятся лишний раз указатель разыменовать.

Ну и мне не понятно, зачем при таком решении этому процессу быть частью nginx и чем это будет отличаться от access-лога и его парсера.

---------- Добавлено 06.02.2014 в 20:55 ----------

Вам проблему обсудить или потроллить? :)

Странно, я тоже ее читал, и не увидел там ничего, кроме статистики.

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

Ну товарищ выше уже сказал - удобством. Лично мне такое не надо, но я и nginx'ом не особо пользуюсь и уже даже рассылку их не читаю ибо качество продукта уже давно не устраивает, боюсь за безопасность.