Pull to refresh

Comments 60

Теперь точно поставлю nginx попробовать :)
Я описал только пару фич nginx, а на самом деле — тысячи их. :) Почему-то все думают, что основная ценность этого сервера в том, что он очень быстрый. А это по моему мнению не так. Самое важное — что он очень-очень гибкий.
Апач какбэ тоже очень гибкий. Но нгинкс быстрее :)
В нжинксе к тому же гибкость достигается куда меньшими трудозатратами. Всё очень лоогичноЮ удобно и превосходно документировано. В сравнении с апачем он чудо. Мне там не хватает лишь пользовательской настройки а-ля .htaccess, но всё равно это неудачное решение, по крайней мере в таком виде, как это реализовано в апаче.
Поясните пожалуйста про неудачное решение пользовательской настройки через .htaccess в апаче.
Может быть, я не иправ, но постоянно обращаться к диску за проверкой наличия .htaccess в директориях — не дело. Конечно, это вопрос правильной настройки, но на большинстве серверов он включен везде
Задать диапазон ip-адресов (например, стрим-москва) уже можно?
Апач гибкий вообще. А нгинкс гибкий как раз там где нужно для высоких нагрузок.
nginx это пораждение BSD-шного склада ума :)

Он до ужаса логичен, прост и быстр. Надо было начинать прбовать уже давно ;)
Лень природная мешает :) Но теперь я буду с ней бороться :)
Из за лени и я долго не ставил — но пришлось поставить из-за того, что апач начал падать.

Очень доволен, хотя конечно трохи с конфигами для ссл и виртуал хостов пришлось поковыряться. Работает стабильно, вопросов по памяти и процеccору никаких, изредка в топе появляется процесс.
Рискую нарваться на кучи минусов, но почему все в Рунете так сходят с ума по nginx'у(да и по sphinx'y)?

Посомтрите на список Tiny Web Servers:
en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers
Ну лично мне мой надежный информатор советовал именно nginx. Потому это будет мой выбор :)
А вы попробуйте выкинуть из этого списка:

а) Всё что closed source (цена и возможность посмотреть как оно работает);
б) Всё, что не работает под Linux и FreeBSD (самые популярные платформы хостинга);
в) Всё, что написано на C#, Ruby, PHP и Python (производительность);
г) Всё что не поддерживается и не обновляется больше года (к кому идти, если нашёл баг?);
д) Всё, что не использовалось в реальных больших и нагруженных проектах (мало ли, что автор обещает);

И что у вас останется? Выбор из, от силы, 3-4 вариантов, среди которых nginx — один из лучших.
Close Source — не обязательно платное, как и Open Source — не обязательно бесплатное!
А зачем смотреть исходники? Должно стабильно работать и выполнять поставленные задачи.

lighttpd, чем не вариант?
Да и возможностей поболее, например давно уже работает с FastCGI
nginx тоже давно fastcgi умеет
хорошая статья, а у меня как раз есть проект где можно оное отлично применить :)
Спасибо. Если народ заинтересуется, я постараюсь продолжить рассказывать про возможности Nginx. Так получилось, что мне приходится использовать этот веб-сервер на довольно нагруженном проекте, так что материалов набралось немало. :)
Народ интересуется.
Очень бы хотелось. Сам вот недавно поставил пока тока на тестовом. Собираюсь на продакшн кидать. Тема очень интересная.
Поскольку про обычную настройку и тюнинг сервера, в интернете, да и на хабре, материалов довольно много, я хочу описывать те фичи, которые используются реже. Возможно, просто потому, что ими мало кто интересовался. :)
Все верно. nginx был первой программой которую я скомпилировал ( в смысле удаленно и на CentOS). Однако про конфигурирование я бы почитал побольше. Материал сильно разрознен.
nginx рельсы вообще круто разгоняет. Прямо чувствуется.
да-да, такие материалы нужны!
Да-да, народ интересуется. Ждем-с
да просьба написать материалов на практическое использование и как можно более подробных
Добавьте в блог nginx для порядка. За статью спасибо, продолжайте в том-же духе:)
Я бы с удовольствием, но пока, к сожалению, могу писать только в свой личный блог. Я тут всего два дня. :)
Странное ограничение по дате регистрации, ну да ладно… :)
Мне кажется, ограничение связано с кармой, хабрасилой, или каким-то ещё параметром, в которых я пока не очень разобрался. Как только разберусь, перенесу запись. :)
UFO landed and left these words here
А если пользователь изменил имя в профиле? Ему надо куки рефрешить?
Спасибо, что заметили. Это представляет собой некоторую проблему. Действительно, в этом случае надо, либо изменить идентификатор сессии в куке (самый простой и логичный вариант), либо какой-то ещё параметр, входящий в строку proxy_cache_key (например args).
Либо руками удалять файл кеша для данной страницы? Или это не самый лучший (простой) вариант?
Вариант не самый лучший, потому как кешем nginx заведует, причём под кеш отдельный процесс выделен — cache manager. Полагаю, что он может обидеться, если в его кеш кто-то со стороны полезет :)
Руками удалять файл из кеша nginx — это не наш метод. :) Тем более, что пути к закешированным файлам могут измениться, причём даже не теоретически. Например, вы решите, что 2-х уровней каталогов для вашего кеша мало, и решите добавить третий.

Всё-таки, в данном случае проще всего просто поменять идентификатор сессии у пользователя в куке.
Да, меня этот вопрос тоже очень интересует.

Если пользователь вышел, поменял имя, ещё что-нибудь сделал? Это как-то можно учесть при кешировании? Или придётся самому сбрасывать кеш?
Если пользователь вышел, то вы, вероятно, очистили ему куку с идентификатором сессии, а значит, более никаких специальных действий предпринимать не надо. Если пользователь поменял имя (или любую другую информацию, которая показывается в закешированном блоке), то вы должны ему поменять идентификатор сессии в куке (ну, и предпринять другие соответствующие действия на сервере), иначе, некоторое время (до 3х часов) ему может показываться блок со старыми данными.
полезно конечно, спасибо, но на мой взгляд подходит только контент-сайтам.
все хорошо только я не понял каким боком первое относится ко второму… мне кажется что без первого (ну т.е. всю страницу отдаем а не кусок) при применении второго нииче не поменяется, я не думаю что чуть возросший объем кешируемых данных сильно скажется на производительности, а галаздо проще и надежнее, не?
Да, можно кешировать страничку целиком, а не только один блок. В данном примере, действительно нет большой разницы, кешировать всю страничку, или только отдельный блок.

Но дело в том, что динамических блоков может быть несколько, с большим количеством вариантов содержимого. И тут уже становится выгоднее кешировать именно блоки по-отдельности. :)
Google, например, умеет определять наличие обновляющихся блоков на страничке и добавляет ей немного кармы (читай, PR).
И откуда же информация такая взялась?
А я успешно занимался SEO с 1997 года по 2007. Поэтому к таким статьям настроен скептически, как и к высказыванию, которое процитировал.
Смотрим вниметельно — во-первых, в статье по этой ссылке написано:
«38 факторов, которые, предположительно, позитивно влияют на позицию при ранжировании Google». (видите слово «предположительно»?).

Во вторых, эти 38 чудо-факторов, которые предположительно влияют, выделены полужирным, а ни один из пунктов 27, 28, 30 не выделен.

Прошу прощения за оффтопик, но глаз режет, когда между делом упоминается какая-нибудь ерунда.
А можно ли например такой блок хранить во внешнем кеше типа memcached? Например генерить набор блоков и кидать их в кеш, а nginx будет их собирать и вставлять в шаблон.
можно memcached на бэкэнд поставить, и из него проверять наличие блоков в кэше =)
В принципе, возможно, хотя лично я такую конфигурацию не пробовал. Возможно, больше про неё сможет рассказать мой друг и хабрачеловек bambr. :)
Неожиданная ссылка я бы сказал :)
Ну, просто, насколько я знаю, он как-раз делал работающую конфигурацию, когда бэкенд сам кладёт прегенерённые блоки в мемкеш, а их оттуда уже забирает nginx, которому, соответственно, на бэкенд ходить практически не надо, разве что только по большим праздникам. :)
Не, просто вы сами попробуйте на эту ссылку нажать))
А про такую конфигурацию было-бы очень интересно почитать, ибо сам хочу применить нечто подобное…
Кхм… ой… одна маленькая опечатка, а такой результат. Жаль, что нельзя редактировать комментарии.
интересно, что быстрее работать будет — кэширование средствами nginx или через memcached?
Тестирование, главный аргумент!
Все просто.

Мемкеш гоняет данные по сети (loopback тоже сеть и тоже ест CPU ПЭВМ), а значит есть накладные расходы.
Nginx отдает статику из локальной fs. А часто отдаваемые данные из fs вообще попадают в active область памяти и отдаются так быстро, что слышно свист.

Истина посередине: кешировать в бекенде (php, perl, python) тяжело доставаемые данные мемкешем, например, на «минуты», а уже фронтендом (nginx) кешировать всю выдачу бекенда на «секунды».

Это решает вопрос смены имени юзера:
— инвалидация кеша мемкеша проще реализуется на уровне бизнес-логики (php,perl,python)
— бекенд (php, perl, python) делает трудоемкие вычисления для этого юзера всего раз в «минуты» (но при смене имени кеш дропается мгновенно)
— фронтенд (nginx) сделает из 100 запросов в «секунды» всего один-единственный инвалидирующий запрос к бекенду

Я, конечно, не разбираюсь в математике и компюторах, но кажется последние два пункта говорят о снижении нагрузки на два порядка.
классический вариант на нагруженном ресурсе именно для это задачи — главная страница чистая статика, а хеадер подтягивается аджаксом — я понимаю что из другой оперы но тоже вариант решения озвученной задачи. Модифицированный варинт но менее надежный — запихивать в куку «имя (логин)» я прямо в статике скриптом выгребать
В случае с аяксом увеличивается количество соединений клиент-сервер
я не говорю что мой метод лучше указанного, я так просто, в тему как один из вариантов и более простой в реализации
Зато можно не каждый раз клиенту отдавать всю страницу, а возвращать 304, не тратя трафик, и догружать динамические компоненты на js.
Разве не именно этот вариант используется на ya.ru?
Only those users with full accounts are able to leave comments. Log in, please.