войти зарегистрироваться

Клиентская оптимизация whois

индекс
107,44

nginx как reverse proxy

Несколько читателей блога webo.in просили меня выложить конфигурацию связки nginx + Apache, на которой работает сервер. Хотя это и не относится напрямую к теме клиентской оптимизации. Однако, большинству специалистов, занимающихся клиентской оптимизацией, будет интересно узнать о настройке нескольких хостов для выдачи статики и пара других трюков, связанных с балансировкой запросов.

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

читать дальше на webo.in →

+4
6 августа 2008, 11:36
sunnybear

комментарии (45)

  • Определённо в закладки!
  • так же апачу нужен 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 блокируется на диске
              Но определенно 100 вокеров nginx лучше 100 процессов апача.
  • Опыт работы с nginx подсказывает
    expires 10y
    заменить на
    expires max

    Иногда (но все же бывает) сервер может спросить установку даты и времени и тогда отдача контента с заголовком Expires на 10 лет не поможет, на помощь приходит параметр "max", который задаёт время 31 декабря 2037 23:55:55 GMT для строки "Expires" и 10 лет для строки "Cache-Control".
  • Велосипедисты, вместо того чтобы жать апачем не проще включить это в nginx-e
    и вообще зачем нагружать апач работой со статикой? это конечно отличный способ загрузить тазик до отказа, но делать так явно не стоит.

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

    ЗЫ:ППЦ насоветую еще, а потом удивляются почему у нас места в датацентрах нету.
  • Если уж разговор об оптимизации, то отдельный хост для картинок - это лишний DNS-Запрос. Даже если картинки хранятся на отдельном сервере, то при возможности лучше сделать так, чтобы они отдавались через одно доменное имя.

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

        Потом, при первом запросе, всё же будет задержка на DNS-разрешение всех псевдонимов, что поменяет картину, а на графиках это не отображено.
        • вполне Вам верю, однако, все же советую ознакомиться с темой. Для меня это тоже было странно поначалу
          • Для меня сейчас главная тема - оптимизация базы данных. 20 миллисекунд как-то трудно сравнить с минутами простоя в момент засоса :-)
    • Если очень много статики (например, мелких картинок, а-ля thumbnails) то можно сделать несколько хостов (около 3-4) для их раздачи, с точки зрения клиента, они *все* загрузятся быстрее из-за параллельности загрузки.
  • В данной конфигурации можно обойтись одним веб-сервером (nginx).
    • это не было задачей данного топика :)
      • Мне тоже кажется, что присутствует некоторое недопонимание того, зачем нежен nginx, раз уж он взят в использование.
        • в названии статьи заявлено, зачем конкретно здесь нужен nginx. Что угодно можно сделать как угодно. Я не говорю, что данная конфигурация оптимальна, я говорю, что она рабочая.
          • Если приделать три апача в ряд, а с конца поставить nginx, то тоже получится рабочая конфигурация
            • самое интересное, что никто не выкладывал тесты производительности таких серверных конфигураций, а языками начесано не на один Гб :)
  • отличная статья
  • fgf
  • огромное спасибо за статью!
  • За что спасибо говорите?

    в статье описан метод как делать не надо!!!
    1 - все реврайты, простую логику выносить в нгинкс, он будет делать это на порядки быстрее,
    2 - раздачу статики в любом виде в нгинкс,
    3 - гзипование апачом как минимум на 15% более ресурсоемко чем nginx-ом.

    gzip on;
    gzip_disable "MSIE [1-6]";
    gzip_min_length 1100;
    gzip_buffers 4 8k;
    gzip_types text/plain text/css text/xml application/x-javascript; //дописать что еще хотите гзиповать туда.

    и все, и не надо ебать мозг.
    • народ увидел "крутые" слова, и ломанулся плюсовать.
      • народ увидел дельные слова
  • нафига жать апачем и отдавать CSS/JS?
  • послушать народ, так зачем вообще этот апач нужен то ? :-)
    всё вынести в nginx
    • Ну многие так и делают ;) Nginx + FastCGI реально рулит.
  • Степень сжатия 9 никто в здравом уме не ставит. При 1 текст жмется на 80% без нагрузки на проц, все остальное даст уменьшение на 1-2% при этом проц загрузишь нипадецки.

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