Видео ролики бесплатно онлайн

Free video online

Официальный сайт ejnews 24/7/365

Смотреть видео бесплатно

cppmm 12.08.2010 19:56

Я рекомендуюNginx - проксирующий http-сервер

"nginx — это HTTP-сервер и почтовый прокси-сервер. Я начал разрабатывать nginx весной 2002 года, а осенью 2004 года вышел первый публично доступный релиз. В декабре 2009 года nginx использовался на 4% самых посещаемых сайтов в мире."
(с) Игорь Сысоев, создатель nginx.

Я постараюсь в кратце рассказать о том, как я сам использую этот сервер. В моём описании будут только краткие примеры и небольшие советы по части HTTP-сервера. За более подробной информацией и по поводу особенностией почтового прокси-сервера лучше обратиться на сайт разработчика и постовляемую с nginx документацию.

nginx vs apache vs lighthttpd vs ещё какой-нибудь http-сервер.

Часто попадаются восторженные отзывы программеров/начинающих админов о том, что nginx быстрее, выше, сильнее чем %servername%. Сразу же скажу, что здесь таких сравнений вы не найдёте. Я не буду сравнивать красное с тёплым. Более-менее плотно мне приходилось работать с apache и nginx, так вот это два разных по задачам сервера. И если кому-то удалось у себя на локалхосте запустить nginx, который, например, оказался быстрее, чем апач - это говорит лишь о том, что на данном конкретном локалхосте для данной конкретной задачи и при данном положении луны в созвездии козерога оно быстрее. К реальности такие тесты отношения не имеют: apache и nginx - разные продукты, предназанченные для разных вещей.

Немного теории.

nginx очень хорошо справляется с отдачей статики(изображения, статический html, таблицы стилей и т.п.). Если точнее, сам по себе nginx в принципе не умеет обрабатывать динамический контент - он может либо проксировать запросы кому-нибудь другому(web-серверу, который умеет; FastCGI-серверу). Т.е. можно "подключить к nginx php". Но для этого надо будет запустить php, как fastcgi и проксировать все запросы. Казалось бы, ничего плохого, но на деле при большой нагрузке те ресурсы, что вы таким образом сэкономите на отказе от апача, вы потеряете на этом самом fastcgi. Да ещё и работает оно не очень стабильно. Поэтому обычно используют решение FrontEnd-сервер + BackEnd-сервер. Я использую связку nginx+apache2, но никто не мешает вам проксировать запросы на любой дургой web-сервер - nginx'у совершенно всё-равно, что стоит за ним - главное, чтобы оно отдавало http. Суть разделения такова - каждый сервер занимается своим делом - один генерирует контент, другой отдаёт его конечному пользователю. Причём, чем особенно хорош nginx, он может ещё и определять по запросам пользователя, какие из них нужно проксировать для генерации ответа, а на какие можно ответить уже сейчас, вытащив из кеша или взяв из настроек нужный контент. А если учесть, что nginx'у можно задавать пути с использованием regexp'ов, то даже представить сложно, насколько гибко можно управлять отдачей содержимого сайта.

И немного практики.

Пример первый: FrontEnd + BackEnd.

Ставим апач, как обычно. Полностью все настройки на ваше усмотрение. Все модули, все особенности - всё делаете так, как привыкли. Только вот слушать апачу нужно будет не 80-ый порт, а любой незанятый. Ну и в целях безопасности не помешает перевести его на 127.0.0.1, чтобы наружу вообще не выглядывал. BackEnd готов.
Устанавливаем nginx и в создаём там виртульный сервер. Примерно так:
 1
2
3
4
5
6
7
8
9
10
server {
listen 80;
server_name
sitename.com
www.sitename.com;
location / {
proxy_pass http://127.0.0.1:8080/;
proxy_redirect off;
}
}


Собственно, этого уже достаточно. Теперь все запросы к nginx будут уходить на апач и там обрабатываться, а отдавать результаты пользователю будет nginx. При этом он уже будет запоминать статику и работать быстрее. Механизм работы таков: запрос, приходящий от пользователя(он идёт через интернеты, поэтому может двигаться долго и нудно), мгновенно передаётся апачу, обрабатывается и мгновенно отдаётся назад nginx'у уже в статическом виде. Ну и nginx, в свою очередь всё это скармливает пользователю. Скорость достигается за счёт того, что апач при обработке и генерации страницы создаёт отдельный процесс. И пока он страницу полностью не отдаст, процесс этот висит в памяти. А nginx эту страницу забирает мгновенно. И дальше уже не важно, как долго пользователь будет её забирать. Плюс к этому на крупных ресурсах запросы пользователей нередко дублируются. И тут тоже видим заметный профит - nginx отдаёт то, что уже сгенерировано даже не дёргая апач.
Едем дальше. У нас на сайте много картинок. Почему бы нам не снять нагрузку по отдаче картинок с апача вообще и переложить её полностью на nginx? Да без проблем. Предположим, все картинки находятся у нас в отдельной директории и доступны по адресы http://sitename.com/images/<имя картинки>
Добавляем в описание виртсервера такие строки:
1
2
3
  location /media {
root /path/to/dir/with/images/;
}


Готово. Теперь nginx сам знает где искать изображения по запросам пользователей и отдаёт их сразу же после запроса.
Как я уже писал, помимо прочего nginx умеет regexp'ы. Например, мы решили разделить нагрузку и всякие media-файлы у нас на одном сервере(с быстрым и сильным каналом), а сам движок на другом, где скорсоти поменьше. Отлично, добавляем:
1
2
3
  location /media/ {
rewrite ^(/media/.*)$ http://mediaserver.com$1;
}


Теперь все запросы идущие на наш сервер типа http://sitename/media/<файл> будут автоматически переписываться на http://mediaserver.com/media/<файл>. Таким образом конечный пользователь будет получать http-страницы и прочее с одного сервера, а картинки, видео и тому подобное с другого.
Ещё по поводу регекспов. Никто не мешает нам использовать их не только в описаниях rewrite, но и в location. Например:
1
2
3
  location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|js|swf)$ {
root /path/to/media/files;
}


В этом примере мы любые запросы к любым изображениям, расположенным по любым путям нашего сайта, отдали в распоряжение nginx.
Ну и так далее. Возможностей куча. Плюс к этому, nginx довольно нехило конфигурится и можно без проблем управлять различными параметрами типа максимально возможного размера загружаемых файлов, ограничения таймаутов, access-листы по ip и т.д. и т.п. Это уже добро пожаловать в маны. Ну и очень хорошие описания директив nginx на сайте автора: http://sysoev.ru/nginx

Пример второй: Шлюзовый сервер.

Имеем сеть - один шлюзовый сервер, единственный из всей сети имеющий доступ в интернет и множество машин в локалке за ним, причём некоторые из них ещё и серверы. Или, другой вариант - разработчик web-проектов использует виртмашины(openvz) для отдельных web-серверов - в каждом контейнере отдельный web-сервер, доступ к которому имеет отдельный программист и делает там всё, что ему угодно. Удобно, когда ошибка одного программера, завесившая апач не мешает другим. Так вот надо всё это выпустить в инет. Чтобы любой человек мог попасть на любой из разрабатываемых сайтов и посмотреть, что там и как. А дать реальный ip каждому контейнеру и каждому компу в локалке возможности нет. Вот тут-то снова приходит на помощь nginx.
В принципе, всё так же, как и в предыдущем примере, только proxy_pass будет не на локалхост, а на серый ip конкретного сервера. Вроде бы ничего особенного. Но вы только представьте, как гибко и легко можно рулить любыми сайтам всей сети, выпуская/закрывая/добавляя/удаляя их. Несколько строк в конфиге nginx, добавляющие виртуальный хост и новый сайт доступен миру. Никаких заморочек с форвардами,пробросами портов, Border Gateway Protocol'ами и прочим.
Или другой вариант по похожей схеме. У вас большой и страшный проект, каждая секунда простоя которого стоит миллионы денег. И железо начинает подавать признаки умирания. Да, конечно, есть backup-сервер, точно копирующий действующий проект, но вот проблема - переключения и т.п. - перебой в работе. А если у нас есть такой вот шлюзовой nginx, мы просто меняем в нём ip директивы proxy_pass и рестартим nginx - проект переключен на другой физический сервер, пользователи даже не заметили.

Я уверен, что это далеко не все возможности http-сервера nginx. Мой пост - что-то типа ознакомительной статьи для тех, кто слышал, но не вкурсе, что же оно такое на самом деле.


Тэги: admin nginx server
+ 20 -
Похожие Поделиться

mhspace 12.08.2010 20:11 #
+ 1 -
Отличная статья, спасибо!
тех, кто слышал, но не вкурсе, что же оно такое на самом деле.

Да, мой случай...

Я, конечно понял, что
За более подробной информацией и по поводу особенностией почтового прокси-сервера лучше обратиться на сайт разработчика и постовляемую с nginx документацию.
Но всё же один мелкий вопрос: я слышал, что nginx не дружит с IPv6, это правда?
xT 12.08.2010 20:38 #
+ 3 -
Но всё же один мелкий вопрос: я слышал, что nginx не дружит с IPv6, это правда?
дружит, но проксировать на IPv6-апстрим не умеет
cppmm 12.08.2010 21:07 #
+ 2 -
Честно говоря, пока даже не вникал и не пробовал.

P.S. Перед написанием статьи я написал письмо автору с просьбой о интервью, но к сожалению, ответа так и не получил, поэтому пришлось всего лишь ограничиться примерами из собственного опыта. Лично мне было бы интересно узнать о том, что сам автор думает о своём сервере и какие у него есть планы по его дальнейшему развитию. Я писал на адрес, указанные на его офф-сайте. Может есть другие способы связи?
xT 12.08.2010 20:14 #
+ 0 -
Для начала отлично : )
cppmm 12.08.2010 21:09 #
+ 0 -
Добавь ещё от себя статейку. Судя по комментам, ты c nginx хорошо знаком, мне тоже будет интересно почитать, что он ещё умеет. :)
xT 12.08.2010 21:10 #
+ 2 -
Я уже про Varnish собрался накатать : )
Volant 12.08.2010 22:32 #
+ 2 -
А я вот знаком с nginx, но совсем ничего не знаю про Varnish.

Интересно было бы почитать про него. Ну и чем они отличаются.
Midler 12.08.2010 20:34 #
+ -1 -
Спасибо!
wiz 12.08.2010 20:42 #
+ 3 -
конфиги nginx рулят.

location /files/ {
gzip off;
location /files/music/ {
alias /mnt/storage1/music/;
}
location /files/video/ {
alias /mnt/storage2/video/;
}
}


Очень редко требуется, но вдруг кто-то найдёт применение (=
xT 12.08.2010 20:44 #
+ 0 -
есть в основной доке, но все равно +
wiz 12.08.2010 20:51 #
+ 0 -
Периодически натыкаюсь на "недокументированые возмжности" во всяких вики. Видимо не успевают все фичи описывать...
predator 12.08.2010 21:04 #
+ 1 -
а чем это отличается от ?
location /media {
root /path/to/dir/with/images/
}
xT 12.08.2010 21:09 #
+ 3 -
тем что он будет искать media в images
и тем что без ; будет ошибка :)
cppmm 12.08.2010 21:18 #
+ 1 -
Спасибо, поправил. :)
cppmm 12.08.2010 21:12 #
+ 2 -
Создание разных location внутри уже существующего location. На практике это помогает, например с django(фреймфорк на питоне). Там есть директория media/, в которой лежит вся статика: и картинки, и скрипты. При помощи такого способа можно сначала отделить весь /media, чтобы отдать его целиком в управление nginx, а потом для скриптов выставить одни параметры, а для тех же картинок, другие.
predator 12.08.2010 21:00 #
+ 0 -
Т.е. можно "подключить к nginx php". Но для этого надо будет запустить php, как fastcgi и проксировать все запросы. Казалось бы, ничего плохого, но на деле при большой нагрузке те ресурсы, что вы таким образом сэкономите на отказе от апача, вы потеряете на этом самом fastcgi.


Неужели запускать каждый раз новый процесс для обработки запроса в апаче делать легче чем проксировать запрос fastcgi-приложению.
cppmm 12.08.2010 21:16 #
+ 3 -
Если использовать схему nginx+apache - да. Я лично с таким встречался на примере php и drupal(около полусотни запросов в секунду и fastcgi ставит сервер раком) и python+django(просто визуально видно, что fastcgi отрабатывает медленнее, чем апач при одном единственном клиенте).
silent 12.08.2010 21:28 #
+ 0 -
На работе nginx + php-fpm, 300-400 запросов в секунду (включая отдачу статики, правда) - все очень хорошо, год назад отказался от apache потому что с ним хуже.
cppmm 12.08.2010 21:42 #
+ 0 -
Вполне возможно. Но, имхо, это частный случай. Я ещё не видел конфигураций, когда грамотно настроенная связка nginx+apache проигрывала отдельно взятому апачу или отдельно взятому nginx'у.
silent 12.08.2010 21:54 #
+ -1 -
мне кажется что наоборот

http://habrahabr.ru/blogs/linux/79225/
http://interfacelab.com/nginx-php-fpm-apc-awesome/

да и вообще http://www.google.ru/search?q=nginx+fpm+apache
cppmm 12.08.2010 22:02 #
+ 0 -
Вы меня невнимательно читали. Я говорил о том, что apache+nginx быстрее, а не просто apache быстрее. В ваших примерах описывается "голый" апач.
silent 12.08.2010 22:13 #
+ 0 -
Да, про это не подумал когда статьи искал. Но тестировал обе связки, правда просто под siege, не под реальным большим потоком настоящих людей. И апач опять оказался медленнее.
Хотя, может и правда что-то не учел в настройке апача.
digiwhite 13.08.2010 18:47 #
+ 0 -
На работе nginx + php-fpm, 300-400 запросов в секунду (включая отдачу статики, правда) - все очень хорошо, год назад отказался от apache потому что с ним хуже.

И чего вас минусанули.
silent 13.08.2010 19:24 #
+ 0 -
Наверное от зависти. Сейчас еще скажу что серверов у меня почти 20, вообще уйду глубоко в минус :)
xT 12.08.2010 22:34 #
+ 0 -
Я лично с таким встречался на примере php и drupal

замени друпал на pressflow, и приятно удивишься перфомансу: )
cppmm 12.08.2010 22:39 #
+ 0 -
Это ты программистам скажи. Моё дело разместить проект в этих ваших интернетах, а на чём он написан - уже не ко мне. :)
xT 12.08.2010 22:41 #
+ 0 -
а и я говорю всё время : )
orkaan 16.08.2010 21:49 #
+ 0 -
Что-то на русском о нём почти ни слова...
xT 17.08.2010 00:31 #
+ -1 -
да и фиг с ним, с этим русским
nikebl 13.08.2010 11:41 #
+ 0 -
Ты просто не умеешь его готовить (С)
Это я про php-fpm :) у меня держит намнооого больше и не один сервер.
orkaan 16.08.2010 21:19 #
+ 0 -
Тоже намучался с Drupal на nginx+fastcgi(lighttpd). Вернулся на nginx+apache2. :)
xtavras 12.08.2010 21:41 #
+ 0 -
Нда, только час назад гуглил nginx vs apache vs lighthttpd, и тоже сделал вывод что нужно смотреть по задачам, так надо хорошо почитать ТЗ, статья чтобы именно немного въехать отличная, спасибо!
le087 12.08.2010 21:54 #
+ 1 -
Отличнейший пост. Вы сподвигли меня на "копнуть по глубже". Такие статьи очень хороший фундамент для понимания и изучения. Рад, что на Welinux есть такие авторы.
cppmm 12.08.2010 21:57 #
+ 0 -
Когда-то давно меня заставили "копнуть поглубже", отказавшись отвечать на мои тупые вопросы и отправив в ман. Я рад, что есть ещё люди, которые готовы копать поглубже просто после прочтения статьи. :)
le087 12.08.2010 22:12 #
+ -1 -
Просто я таки намылился сделать себе домашнюю страничку. Заодно решил разобраться в десятке туманных для меня вопросов. Поставил себе lighttpd, просто попробовать, худо-бедно поставил django (mysql кстати до сих пор не прикрутил) и на третий день мозги поплыли. А сейчас появилось еще поле для экспериментов =)
silent 12.08.2010 21:57 #
+ 2 -
Кстати да, отличный ресурс есть по теме - http://wiki.nginx.org
cppmm 12.08.2010 22:03 #
+ 0 -
Ух ты. А мне раньше как-то не попадался. Спасибо.
razum2um 12.08.2010 22:02 #
+ 0 -
А nginx эту страницу забирает мгновенно

всегда был против кэширования всей страницы.
как быть если блоки? (если не memcached)

Удобно, когда ошибка одного программера, завесившая апач не мешает другим

а чисто интересно, насколько прожорлива куча индейцев в сумме всех контейнеров?
silent 12.08.2010 22:09 #
+ 1 -
а он и не кеширует (если его специально для этого не настроить).
а вот я придерживаюсь того, что кешировать надо все что обновляется реже чем раз в секунду.
cppmm 12.08.2010 22:10 #
+ 1 -
всегда был против кэширования всей страницы.
как быть если блоки? (если не memcached)

Я не говорил, что он её кеширует. Я сказал, что он её забирает и передаёт пользователю. :) Параметры кеширования отдельно настраиваются для каждого виртсервера nginx.
а чисто интересно, насколько прожорлива куча индейцев в сумме всех контейнеров?

На четырёх ядрах по 2.3 MHz каждое и 8-ми гигах ОЗУ крутилось почти 50 виртмашин с апачами без проблем. Только вот каждой из этих виртмашин можно отдать определённое количество ресурсов системы таким образом, чтобы оно на мешало остальным. Ну и там не только с апачем - в каждой из них жила своя бд и т.п.
predator 12.08.2010 23:35 #
+ 1 -
как быть если блоки? (если не memcached)

Оно?
silent 13.08.2010 00:24 #
+ 0 -
Как-то с любым кешером, мне кажется, это сделать проще и удобнее. Даже если во временный файл запихнуть.
Username 13.08.2010 01:17 #
+ 0 -
спасибо
cppmm 13.08.2010 01:36 #
+ 0 -
Да, отдельные респекты Username. Он меня пнул на написание этого поста. :)
Правда, я не осилил полноценный пост, там посмотрим. Надеюсь, автор ответит.
Minoru 14.08.2010 00:31 #
+ 0 -
http://sitename.com/images/<имя картинки>
location /media {
root /path/to/dir/with/images/;
}
Что-то не так — то images, то media…

Спасибо за статью!
solomenikm 14.08.2010 00:34 #
+ 0 -
Паралельно теме про nginx невоял свой конфиг для друпала http://drupal.ru/node/48471. Думал там людям интересней эта тема будет, а оказывается нет...
solomenikm 14.08.2010 00:37 #
+ 0 -
Хотя конфиг не только для друпала катит, думаю любой движек на нем запахал бы на ура. Просто, ИМХО, тема эта как-то больше про web чем про *nix.
idler 14.08.2010 13:32 #
+ 3 -
Исправьте пожалуйста!!!! Автор nginx ИГОРЬ СЫСОЕВ.
cppmm 15.08.2010 03:21 #
+ 0 -
В упор не понимаю, как я так мог пропариться. Спасибо. Исправил.
Murz 10.09.2010 11:36 #
+ 0 -
А у меня вот задача - отдавать на одном домене несколько статических файлов (по 20-50 кбайт) очень часто, и всё. Повесить могу это всё на отдельный порт, апач тут уже совсем не нужен будет.

И вот не знаю что выбрать - nginx или lighttpd - посоветуйте пожалуйста.
Кто из них будет меньше памяти и ресурсов есть при такой задаче?
cppmm 09.12.2010 14:39 #
+ 0 -
nginx

В хорошем качестве hd видео

Онлайн видео бесплатно


Смотреть русское с разговорами видео

Online video HD

Видео скачать на телефон

Русские фильмы бесплатно

Full HD video online

Смотреть видео онлайн

Смотреть HD видео бесплатно

School смотреть онлайн