В том, что «произвольную динамику» в самом nginx можно генерить только встроенным перлом, который может существенно замедлить работу сервера. За другими видами динамики надо обращаться куда-то «наружу», например, хотя бы и к FastCGI. По-поводу выбора между Apache и FastCGI, могу только предположить, что это не апач плохой, а, скорее, mod_php. :) Хотя, вообще, дело вкуса. :)
На текущий момент работа с IO во встроенном перле (не скажу что невозможна) сложна. К тому же, это заметно скажется на производительности сервера. Однако, возможно, через некоторое время будет сделана более тесная интеграция, с возможностью использовать в интерпретаторе Перла «IO-движок» nginx-а. Есть даже предположения по поводу того, как именно она будет работать, но это дело не самого близкого будущего.
Ну потому что скрипты, генерящие динамику должны где-то выполняться. Это может быть Апач с mod_perl/mod_php/mod_что-то-ещё, или FastCGI, или даже ваш собственный сервер на C/C++. Апач — просто одно из самых популярных, простых и надёжных решений.
Честно говоря, мне кажется более простым, управлять кешированием при помощи заголовков, задающих expiration-time. Генерация и проверка ETag-ов — обычно требует какой-то нагрузки на сервер, а лучший HTTP запрос, с точки зрения высокой нагрузки, это запрос, которого не было. :)
Я уточнил у Игоря Сысоева. Он сказал примерно следующее. Если вы попытаетесь сделать внутри вашего модуля асинхронный запрос на IO (например, через AIO write), то потом (если тот запрос, который вызвал этот write ещё цел), у вас всё-таки есть возможность добраться обратно до объекта запроса. То есть, то что вы хотите возможно, но я до сих пор не вполне понимаю, зачем это может понадобиться.
Nginx гораздо быстрее апача в статике. :) А вот динамику под ним действительно генерить сложно. Поэтому, nginx обычно используется в качестве фронт-энда, который полностью выполняет запросы к статике, а также проксирует (и иногда кеширует) запросы к скриптам. В качестве бэкенда может выступать Apache + mod_perl (как в моём случае), или, например, FastCGI + что-угодно. :)
Отдавать статику апачем, довольно невыгодно по многим причинам. Например, в самом худшем случае, на запрос к однопиксельной гиф-картинке может произойти форк или создание треда, со всеми волнующими последствиями, типа старта mod_perl и его startup-хэндлеров. Поскольку nginx в процессе работы не форкается, такая проблема в нём исключена. :)
Зато это действительно полное и качественное описание архитектуры современных операционных систем. Прочтение этой книжки даёт программисту плюс десять к сообразительности и повышает вероятность спасброска от багов при написании многопоточных приложений до 80%. :)
Хороший вопрос. :) Хотя, честно говоря, я не совсем понимаю, зачем может понадобиться контекст текущего соединения после асинхронной записи в лог. Если вы собираетесь записывать какие-то критичные данные, от результата записи которых зависит дальнейшее выполнение запроса, полагаю, вам всё-равно не обойтись без блокировки (хотя я уточню ещё), а если это действительно, «просто лог», то можно сделать неблокирующуюся запись в лог, и продолжить работу с соединением.
Должен признаться, что в написании модулей для nginx, я не вполне компетентен, так что лучше я, при случае, спрошу Игоря, возможно он сможет что-то более конкретное сказать. Но, полагаю, ему тоже понадобится более подробное описание ситуации.
Я имел в виду epoll, kevent и kqueue для Linux и FreeBSD. Конечно же, «недавно» только относительно всей истории развития Unix-систем. Для сравнения — select, который существует уже с незапамятных времён. :)
Спасибо. Я старался уместить минимально необходимый объём инфы в короткую статью. Понятно, что для опытных разработчиков, бОльшая часть этой статьи представляет перечисление известных фактов. :)
Интересная статья, хотя в ней есть пара небольших неточностей. Собственно, вот что-то в этом духе я и имел в виду, когда говорил, что про общую настройку nginx уже написано довольно много, и я не хочу повторяться.
Продолжение, с примерами и конфигами, конечно следует, но, видимо, уже на следующей неделе. К сожалению, у меня остаётся не так много времени, чтобы писать тексты, но я постараюсь. :)
Ну, просто, насколько я знаю, он как-раз делал работающую конфигурацию, когда бэкенд сам кладёт прегенерённые блоки в мемкеш, а их оттуда уже забирает nginx, которому, соответственно, на бэкенд ходить практически не надо, разве что только по большим праздникам. :)
а) Всё что closed source (цена и возможность посмотреть как оно работает);
б) Всё, что не работает под Linux и FreeBSD (самые популярные платформы хостинга);
в) Всё, что написано на C#, Ruby, PHP и Python (производительность);
г) Всё что не поддерживается и не обновляется больше года (к кому идти, если нашёл баг?);
д) Всё, что не использовалось в реальных больших и нагруженных проектах (мало ли, что автор обещает);
И что у вас останется? Выбор из, от силы, 3-4 вариантов, среди которых nginx — один из лучших.
Руками удалять файл из кеша nginx — это не наш метод. :) Тем более, что пути к закешированным файлам могут измениться, причём даже не теоретически. Например, вы решите, что 2-х уровней каталогов для вашего кеша мало, и решите добавить третий.
Всё-таки, в данном случае проще всего просто поменять идентификатор сессии у пользователя в куке.
Если пользователь вышел, то вы, вероятно, очистили ему куку с идентификатором сессии, а значит, более никаких специальных действий предпринимать не надо. Если пользователь поменял имя (или любую другую информацию, которая показывается в закешированном блоке), то вы должны ему поменять идентификатор сессии в куке (ну, и предпринять другие соответствующие действия на сервере), иначе, некоторое время (до 3х часов) ему может показываться блок со старыми данными.
Отдавать статику апачем, довольно невыгодно по многим причинам. Например, в самом худшем случае, на запрос к однопиксельной гиф-картинке может произойти форк или создание треда, со всеми волнующими последствиями, типа старта mod_perl и его startup-хэндлеров. Поскольку nginx в процессе работы не форкается, такая проблема в нём исключена. :)
Должен признаться, что в написании модулей для nginx, я не вполне компетентен, так что лучше я, при случае, спрошу Игоря, возможно он сможет что-то более конкретное сказать. Но, полагаю, ему тоже понадобится более подробное описание ситуации.
а) Всё что closed source (цена и возможность посмотреть как оно работает);
б) Всё, что не работает под Linux и FreeBSD (самые популярные платформы хостинга);
в) Всё, что написано на C#, Ruby, PHP и Python (производительность);
г) Всё что не поддерживается и не обновляется больше года (к кому идти, если нашёл баг?);
д) Всё, что не использовалось в реальных больших и нагруженных проектах (мало ли, что автор обещает);
И что у вас останется? Выбор из, от силы, 3-4 вариантов, среди которых nginx — один из лучших.
Всё-таки, в данном случае проще всего просто поменять идентификатор сессии у пользователя в куке.