Comments 60
Теперь точно поставлю nginx попробовать :)
Я описал только пару фич nginx, а на самом деле — тысячи их. :) Почему-то все думают, что основная ценность этого сервера в том, что он очень быстрый. А это по моему мнению не так. Самое важное — что он очень-очень гибкий.
Апач какбэ тоже очень гибкий. Но нгинкс быстрее :)
В нжинксе к тому же гибкость достигается куда меньшими трудозатратами. Всё очень лоогичноЮ удобно и превосходно документировано. В сравнении с апачем он чудо. Мне там не хватает лишь пользовательской настройки а-ля .htaccess, но всё равно это неудачное решение, по крайней мере в таком виде, как это реализовано в апаче.
Апач гибкий вообще. А нгинкс гибкий как раз там где нужно для высоких нагрузок.
nginx это пораждение BSD-шного склада ума :)
Он до ужаса логичен, прост и быстр. Надо было начинать прбовать уже давно ;)
Он до ужаса логичен, прост и быстр. Надо было начинать прбовать уже давно ;)
Рискую нарваться на кучи минусов, но почему все в Рунете так сходят с ума по nginx'у(да и по sphinx'y)?
Посомтрите на список Tiny Web Servers:
en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers
Посомтрите на список Tiny Web Servers:
en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers
Ну лично мне мой надежный информатор советовал именно nginx. Потому это будет мой выбор :)
А вы попробуйте выкинуть из этого списка:
а) Всё что closed source (цена и возможность посмотреть как оно работает);
б) Всё, что не работает под Linux и FreeBSD (самые популярные платформы хостинга);
в) Всё, что написано на C#, Ruby, PHP и Python (производительность);
г) Всё что не поддерживается и не обновляется больше года (к кому идти, если нашёл баг?);
д) Всё, что не использовалось в реальных больших и нагруженных проектах (мало ли, что автор обещает);
И что у вас останется? Выбор из, от силы, 3-4 вариантов, среди которых nginx — один из лучших.
а) Всё что closed source (цена и возможность посмотреть как оно работает);
б) Всё, что не работает под Linux и FreeBSD (самые популярные платформы хостинга);
в) Всё, что написано на C#, Ruby, PHP и Python (производительность);
г) Всё что не поддерживается и не обновляется больше года (к кому идти, если нашёл баг?);
д) Всё, что не использовалось в реальных больших и нагруженных проектах (мало ли, что автор обещает);
И что у вас останется? Выбор из, от силы, 3-4 вариантов, среди которых nginx — один из лучших.
хорошая статья, а у меня как раз есть проект где можно оное отлично применить :)
Спасибо. Если народ заинтересуется, я постараюсь продолжить рассказывать про возможности Nginx. Так получилось, что мне приходится использовать этот веб-сервер на довольно нагруженном проекте, так что материалов набралось немало. :)
Народ интересуется.
Очень бы хотелось. Сам вот недавно поставил пока тока на тестовом. Собираюсь на продакшн кидать. Тема очень интересная.
nginx рельсы вообще круто разгоняет. Прямо чувствуется.
да-да, такие материалы нужны!
Да-да, народ интересуется. Ждем-с
да просьба написать материалов на практическое использование и как можно более подробных
Добавьте в блог nginx для порядка. За статью спасибо, продолжайте в том-же духе:)
Странное ограничение по дате регистрации, ну да ладно… :)
UFO just landed and posted this here
А если пользователь изменил имя в профиле? Ему надо куки рефрешить?
Спасибо, что заметили. Это представляет собой некоторую проблему. Действительно, в этом случае надо, либо изменить идентификатор сессии в куке (самый простой и логичный вариант), либо какой-то ещё параметр, входящий в строку proxy_cache_key (например args).
Либо руками удалять файл кеша для данной страницы? Или это не самый лучший (простой) вариант?
Вариант не самый лучший, потому как кешем nginx заведует, причём под кеш отдельный процесс выделен — cache manager. Полагаю, что он может обидеться, если в его кеш кто-то со стороны полезет :)
Руками удалять файл из кеша nginx — это не наш метод. :) Тем более, что пути к закешированным файлам могут измениться, причём даже не теоретически. Например, вы решите, что 2-х уровней каталогов для вашего кеша мало, и решите добавить третий.
Всё-таки, в данном случае проще всего просто поменять идентификатор сессии у пользователя в куке.
Всё-таки, в данном случае проще всего просто поменять идентификатор сессии у пользователя в куке.
Согласен :)
Просто раньше не задавался вопросом смены SID'а в PHP-приложениях, а теперь нашёл простое решение.
Просто раньше не задавался вопросом смены SID'а в PHP-приложениях, а теперь нашёл простое решение.
Да, меня этот вопрос тоже очень интересует.
Если пользователь вышел, поменял имя, ещё что-нибудь сделал? Это как-то можно учесть при кешировании? Или придётся самому сбрасывать кеш?
Если пользователь вышел, поменял имя, ещё что-нибудь сделал? Это как-то можно учесть при кешировании? Или придётся самому сбрасывать кеш?
Если пользователь вышел, то вы, вероятно, очистили ему куку с идентификатором сессии, а значит, более никаких специальных действий предпринимать не надо. Если пользователь поменял имя (или любую другую информацию, которая показывается в закешированном блоке), то вы должны ему поменять идентификатор сессии в куке (ну, и предпринять другие соответствующие действия на сервере), иначе, некоторое время (до 3х часов) ему может показываться блок со старыми данными.
полезно конечно, спасибо, но на мой взгляд подходит только контент-сайтам.
все хорошо только я не понял каким боком первое относится ко второму… мне кажется что без первого (ну т.е. всю страницу отдаем а не кусок) при применении второго нииче не поменяется, я не думаю что чуть возросший объем кешируемых данных сильно скажется на производительности, а галаздо проще и надежнее, не?
Да, можно кешировать страничку целиком, а не только один блок. В данном примере, действительно нет большой разницы, кешировать всю страничку, или только отдельный блок.
Но дело в том, что динамических блоков может быть несколько, с большим количеством вариантов содержимого. И тут уже становится выгоднее кешировать именно блоки по-отдельности. :)
Но дело в том, что динамических блоков может быть несколько, с большим количеством вариантов содержимого. И тут уже становится выгоднее кешировать именно блоки по-отдельности. :)
Google, например, умеет определять наличие обновляющихся блоков на страничке и добавляет ей немного кармы (читай, PR).
И откуда же информация такая взялась?
И откуда же информация такая взялась?
Я не специалист по SEO, но мне казалось, что этот факт общеизвестен. Можно посмотреть, например, тут: webest.info/seo/google/google-pr-ratings.php (пункты 27,28,30).
А я успешно занимался SEO с 1997 года по 2007. Поэтому к таким статьям настроен скептически, как и к высказыванию, которое процитировал.
Смотрим вниметельно — во-первых, в статье по этой ссылке написано:
«38 факторов, которые, предположительно, позитивно влияют на позицию при ранжировании Google». (видите слово «предположительно»?).
Во вторых, эти 38 чудо-факторов, которые предположительно влияют, выделены полужирным, а ни один из пунктов 27, 28, 30 не выделен.
Прошу прощения за оффтопик, но глаз режет, когда между делом упоминается какая-нибудь ерунда.
Смотрим вниметельно — во-первых, в статье по этой ссылке написано:
«38 факторов, которые, предположительно, позитивно влияют на позицию при ранжировании Google». (видите слово «предположительно»?).
Во вторых, эти 38 чудо-факторов, которые предположительно влияют, выделены полужирным, а ни один из пунктов 27, 28, 30 не выделен.
Прошу прощения за оффтопик, но глаз режет, когда между делом упоминается какая-нибудь ерунда.
А можно ли например такой блок хранить во внешнем кеше типа memcached? Например генерить набор блоков и кидать их в кеш, а nginx будет их собирать и вставлять в шаблон.
можно memcached на бэкэнд поставить, и из него проверять наличие блоков в кэше =)
В принципе, возможно, хотя лично я такую конфигурацию не пробовал. Возможно, больше про неё сможет рассказать мой друг и хабрачеловек bambr. :)
Я пытался у юзера tigrenokразузнать про такой способ работы нгинкса с мемкешем (он писал тут habrahabr.ru/blogs/startup/60915/ ) но что-то молчит)))
интересно, что быстрее работать будет — кэширование средствами nginx или через memcached?
Тестирование, главный аргумент!
Все просто.
Мемкеш гоняет данные по сети (loopback тоже сеть и тоже ест CPU ПЭВМ), а значит есть накладные расходы.
Nginx отдает статику из локальной fs. А часто отдаваемые данные из fs вообще попадают в active область памяти и отдаются так быстро, что слышно свист.
Истина посередине: кешировать в бекенде (php, perl, python) тяжело доставаемые данные мемкешем, например, на «минуты», а уже фронтендом (nginx) кешировать всю выдачу бекенда на «секунды».
Это решает вопрос смены имени юзера:
— инвалидация кеша мемкеша проще реализуется на уровне бизнес-логики (php,perl,python)
— бекенд (php, perl, python) делает трудоемкие вычисления для этого юзера всего раз в «минуты» (но при смене имени кеш дропается мгновенно)
— фронтенд (nginx) сделает из 100 запросов в «секунды» всего один-единственный инвалидирующий запрос к бекенду
Я, конечно, не разбираюсь в математике и компюторах, но кажется последние два пункта говорят о снижении нагрузки на два порядка.
Мемкеш гоняет данные по сети (loopback тоже сеть и тоже ест CPU ПЭВМ), а значит есть накладные расходы.
Nginx отдает статику из локальной fs. А часто отдаваемые данные из fs вообще попадают в active область памяти и отдаются так быстро, что слышно свист.
Истина посередине: кешировать в бекенде (php, perl, python) тяжело доставаемые данные мемкешем, например, на «минуты», а уже фронтендом (nginx) кешировать всю выдачу бекенда на «секунды».
Это решает вопрос смены имени юзера:
— инвалидация кеша мемкеша проще реализуется на уровне бизнес-логики (php,perl,python)
— бекенд (php, perl, python) делает трудоемкие вычисления для этого юзера всего раз в «минуты» (но при смене имени кеш дропается мгновенно)
— фронтенд (nginx) сделает из 100 запросов в «секунды» всего один-единственный инвалидирующий запрос к бекенду
Я, конечно, не разбираюсь в математике и компюторах, но кажется последние два пункта говорят о снижении нагрузки на два порядка.
классический вариант на нагруженном ресурсе именно для это задачи — главная страница чистая статика, а хеадер подтягивается аджаксом — я понимаю что из другой оперы но тоже вариант решения озвученной задачи. Модифицированный варинт но менее надежный — запихивать в куку «имя (логин)» я прямо в статике скриптом выгребать
В случае с аяксом увеличивается количество соединений клиент-сервер
я не говорю что мой метод лучше указанного, я так просто, в тему как один из вариантов и более простой в реализации
Зато можно не каждый раз клиенту отдавать всю страницу, а возвращать 304, не тратя трафик, и догружать динамические компоненты на js.
Разве не именно этот вариант используется на ya.ru?
Разве не именно этот вариант используется на ya.ru?
Sign up to leave a comment.
Кешируем блоки HTML при помощи nginx