Как стать автором
Обновить

Комментарии 46

Определённо в закладки!
так же апачу нужен mod_rpaf для корректной работы с nginx
необязательно, можно смотреть и на x-real-ip для определения ip, и обойтись без mod_rpaf
а можно поподробнее?
Подробнее: Вам придется переписывать ту часть кода, что работает с определением IP адреса пользователя.
Можно, только тогда в логах апача будет ерунда.
Интересно.
Только одна мелочь - по-моему
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d

можно заменить на просто
RewriteCond %{REQUEST_FILENAME} !-d


А nginx отдает только определенный набор картинок?
Чего всю статику через него не отдаете?
статики не так много, а CSS/JS отдается через Apache, ибо вся Rewrite-логика под него писана
по-моему, всю логику раздачи статики можно написать на nginx и трогать Apache только когда нужно :)
боюсь, прав автор
http://webo.in/articles/all/10-frontend-…
все упрется в дисковые операции. Прочитать и отдать статику умеет быстро как nginx, так и Apache.
НЛО прилетело и опубликовало эту надпись здесь
и? где тесты производительности?
НЛО прилетело и опубликовало эту надпись здесь
Опыт работы с nginx подсказывает
expires 10y
заменить на
expires max

Иногда (но все же бывает) сервер может спросить установку даты и времени и тогда отдача контента с заголовком Expires на 10 лет не поможет, на помощь приходит параметр "max", который задаёт время 31 декабря 2037 23:55:55 GMT для строки "Expires" и 10 лет для строки "Cache-Control".
НЛО прилетело и опубликовало эту надпись здесь
Если уж разговор об оптимизации, то отдельный хост для картинок - это лишний DNS-Запрос. Даже если картинки хранятся на отдельном сервере, то при возможности лучше сделать так, чтобы они отдавались через одно доменное имя.

Ну и то, что апач никаким сжатием заниматься не должен, мне кажется, тоже очевидно.
А разве результаты DNS-запросов не кэшируются?
Чтобы что-то закешировать, надо что-то спросить
Всё равно не вижу проблемы.
При первом обращении к example.com клиент в любом случае делает DNS-запрос.
Сделать ещё один для img.example.com - не такая уж и проблема, учитывая что это просиходит всего один раз, зато даёт много вкусных плюшек в перспективе :)
Не пробовал такого, но для меня как-то странно, что браузер не может сравнить ip-адрес, а знает только доменное имя. Может, всё же, имеется в виду то, что у всех псевдонимов должен быть отдельный адрес?

Потом, при первом запросе, всё же будет задержка на DNS-разрешение всех псевдонимов, что поменяет картину, а на графиках это не отображено.
вполне Вам верю, однако, все же советую ознакомиться с темой. Для меня это тоже было странно поначалу
Для меня сейчас главная тема - оптимизация базы данных. 20 миллисекунд как-то трудно сравнить с минутами простоя в момент засоса :-)
Если очень много статики (например, мелких картинок, а-ля thumbnails) то можно сделать несколько хостов (около 3-4) для их раздачи, с точки зрения клиента, они *все* загрузятся быстрее из-за параллельности загрузки.
В данной конфигурации можно обойтись одним веб-сервером (nginx).
это не было задачей данного топика :)
Мне тоже кажется, что присутствует некоторое недопонимание того, зачем нежен nginx, раз уж он взят в использование.
в названии статьи заявлено, зачем конкретно здесь нужен nginx. Что угодно можно сделать как угодно. Я не говорю, что данная конфигурация оптимальна, я говорю, что она рабочая.
Если приделать три апача в ряд, а с конца поставить nginx, то тоже получится рабочая конфигурация
самое интересное, что никто не выкладывал тесты производительности таких серверных конфигураций, а языками начесано не на один Гб :)
НЛО прилетело и опубликовало эту надпись здесь
народ увидел "крутые" слова, и ломанулся плюсовать.
народ увидел дельные слова
нафига жать апачем и отдавать CSS/JS?
послушать народ, так зачем вообще этот апач нужен то ? :-)
всё вынести в nginx
Ну многие так и делают ;) Nginx + FastCGI реально рулит.
Степень сжатия 9 никто в здравом уме не ставит. При 1 текст жмется на 80% без нагрузки на проц, все остальное даст уменьшение на 1-2% при этом проц загрузишь нипадецки.

Вообще все это жевано еще в 2001 году. И я не стал бы боготворить nginx, на больших объемах трафа (больше 50мбпс) не всегда корректно работает. 1.3.41 апач собранный в статик без излишеств пашет, порой, быстрее.
НЛО прилетело и опубликовало эту надпись здесь
хм.. у Вас сервер обслуживает один проект? если так, то на кой Вам вообще апач?
я привел конфиг для одного проекта. Зачем его дублировать 100 раз с незначительными изменениями здесь?
Я ничуть не умоляю значимость статьи, мне просто интересно почему Вы пошли по этому пути. Для чего в Вашем случае апач, вроде как и без него прекрасно можно обойтись.
к черту значимость :) Просто было интересно поставить именно такую связку. До этого с nginx не работал, настраивать все конкретно под него не было желания, а по косвенным признакам серверная производительность не сильно меняется.
Прочитал эту статьи и наблу Дмитрия Котерова "50. Заметки про фронтенды, бэкенды, балансировщики и тому подобное" (http://dklab.ru/chicken/nablas/50.html) - в последней более подробно описано о Reverse proxy и её сути. Стоило бы и на страницах этого поста определить суть этого понятия, если оно раньше не встречалось.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.