Nginx-as-reverse-proxy - Історія редагувань

WikiSysop в 08:34, 8 квітня 2009

2009-04-08T08:34:49Z

WikiSysop в 08:31, 8 квітня 2009

2009-04-08T08:31:00Z

WikiSysop в 10:09, 25 березня 2009

2009-03-25T10:09:59Z

WikiSysop в 10:09, 25 березня 2009

2009-03-25T10:09:31Z

WikiSysop в 10:08, 25 березня 2009

2009-03-25T10:08:51Z

WikiSysop в 10:04, 25 березня 2009

2009-03-25T10:04:42Z

WikiSysop в 10:04, 25 березня 2009

2009-03-25T10:04:19Z

WikiSysop в 10:02, 25 березня 2009

2009-03-25T10:02:00Z

WikiSysop в 09:57, 25 березня 2009

2009-03-25T09:57:52Z

WikiSysop в 09:57, 25 березня 2009

2009-03-25T09:57:08Z

@@ Рядок 20: / Рядок 20: @@
 Вот примерная диаграма предложенной конфигурации веб-сервера:
-[[img:general c.png]]
+[[Image:general c.png]]
 В дополнение к описанному, Вы получите еще очень удобную возможность так называемых контролируемых закачек, которая будет описана ниже.
@@ Рядок 28: / Рядок 28: @@
 В конфигурации с использованием nginx как frontend-сервера, Вы имеете возможность создать простое правило для переписывания ссылок в запросах так, чтобы все красивые ссылки типа http://your.cool-service.com/files/cool.mp3 автоматически направлялись на некоторый скрипт /down.php и, если он вернет заголовок X-Accel-Redirect, файл автоматически отдавался клиенту с поддержкой Ranges и всех остальных прелестей раздачи статического контента с frontend-сервера. Backend-сервер в это время сможет обрабатывать другие запросы. Ваши пользователи могут даже не знать о том, что их закачки контролируются Вами. Примерная диаграмма описанного алгоритма приведена ниже:
-[[img:algorithm c.jpg]]
+[[Image:algorithm c.jpg]]
 <br> Позвольте обратить Ваше внимание на важный факт: Если Вам нужно только увеличение производительности работы сайта с помощью описанной здесь техники, и вы не хотите использовать систему контроля за скачиванием, то '''Вам не нужно ничено менять в скриптах на Вашем сервере!''' Они будут работать так же, как и раньше!

@@ Рядок 1: / Рядок 1: @@
-== Использование Nginx Как Reverse-Proxy Сервера На Загруженных Сайтах ==
+== Использование Nginx Как Reverse-Proxy Сервера На Загруженных Сайтах  ==
-Две недели назад мы запустили новую версию одного из наших оcновных веб-проектов и начали массивную рекламную поддержку этого сайта. В результате рекламы, исходящий трафик только с одного сервера достиг 200-250Mbit/s! В данной статье я опишу, как построить стабильный и эффективный веб-сайт с двухуровневой архитектурой обработки запросов (с двумя веб-серверами: frontend и backend) или как модифицировать ваш текущий сервер, чтобы получить дополнительные ресурсы для обработки большего количества запросов.
+[ http://blog.kovyrin.net/2006/05/18/nginx-as-reverse-proxy/lang/ru/ | Оргигинал ]
-Для начала, опишу типичный процесс обслуживания запроса к веб-серверу и структуру самого сервера:
+Две недели назад мы запустили новую версию одного из наших оcновных веб-проектов и начали массивную рекламную поддержку этого сайта. В результате рекламы, исходящий трафик только с одного сервера достиг 200-250Mbit/s! В данной статье я опишу, как построить стабильный и эффективный веб-сайт с двухуровневой архитектурой обработки запросов (с двумя веб-серверами: frontend и backend) или как модифицировать ваш текущий сервер, чтобы получить дополнительные ресурсы для обработки большего количества запросов.
 . Клиент инициирует запрос к серверу.
@@ Рядок 13: / Рядок 14: @@
 . Браузер клиента получает ответ, закрывает соединение с сервером и отображает “ответ”.
 Как видите, если к серверу приходит очень много запросов, он должен создавать много параллельных потоков/процессов и держать их в памяти, пока клиент не закроет соединение. Если соединение у клиента не быстрое, то серверные процессы будут висеть в памяти достаточно долго и используемые ими ресурсы будут увеличиваться очень быстро.
-[[Зображення:general_c.png]]
+Как же решить данную проблему? Простым решением может быть бесконечное увеличение объемов оперативной памяти на сервере и покупка дополнительных или более мощных процессоров в ожидании момента, когда сервер умрет под нагрузкой… Но существует более эффективное решение! Вы можете просто поместить небольшую программку (nginx, например) перед Вашим большим веб-сервером и дать ей возможность обслуживать запросы к статическим файлам, а запросы к динамике проксировать к главному серверу. При таком решении Ваш большой сервер не будет создавать дополнительных процессов для обработки статических страниц и файлов и будет отдавать результаты обработки динамических запросов маленькому frontend-серверу очень быстро, что позволит ему освободить ресурсы для использования в обработке других запросов. Маленький frontend же может ждать сколь угодно долго, пока клиент заберет свой “ответ” и закроет соединение, а backend не будет тратить ресурсы для этого!
-В дополнение к описанному, Вы получите еще очень удобную возможность так называемых контролируемых закачек, которая будет описана ниже.
+Вот примерная диаграма предложенной конфигурации веб-сервера:
-Если Ваш сервер содержит какие-то статические ресурсы, которые можно скачивать только определенной части аудитории сайта (контент-провайдеры могут предоставлять возможность скачивания mp3-файлов только пользователям с положительным балансом; некоторые сайты дают скачивать файлы только зарегистрированным пользователям и т.п.), в типичном случае вам необходимо создать некий скрипт для обработки запросов на скачивание и создать набор жутких ссылок вида http://some.service.com/down.php?file=xxx.mp3… В дополнение к этому Ваши пользователи не будут иметь возможность докачки (исключая те случаи, когда Ваш скрипт настолько сложен, что понимает заголовок Ranges в HTTP-запросах)…
+В дополнение к описанному, Вы получите еще очень удобную возможность так называемых контролируемых закачек, которая будет описана ниже.
-В конфигурации с использованием nginx как frontend-сервера, Вы имеете возможность создать простое правило для переписывания ссылок в запросах так, чтобы все красивые ссылки типа http://your.cool-service.com/files/cool.mp3 автоматически направлялись на некоторый скрипт /down.php и, если он вернет заголовок X-Accel-Redirect, файл автоматически отдавался клиенту с поддержкой Ranges и всех остальных прелестей раздачи статического контента с frontend-сервера. Backend-сервер в это время сможет обрабатывать другие запросы. Ваши пользователи могут даже не знать о том, что их закачки контролируются Вами. Примерная диаграмма описанного алгоритма приведена ниже:
+<br> Если Ваш сервер содержит какие-то статические ресурсы, которые можно скачивать только определенной части аудитории сайта (контент-провайдеры могут предоставлять возможность скачивания mp3-файлов только пользователям с положительным балансом; некоторые сайты дают скачивать файлы только зарегистрированным пользователям и т.п.), в типичном случае вам необходимо создать некий скрипт для обработки запросов на скачивание и создать набор жутких ссылок вида http://some.service.com/down.php?file=xxx.mp3… В дополнение к этому Ваши пользователи не будут иметь возможность докачки (исключая те случаи, когда Ваш скрипт настолько сложен, что понимает заголовок Ranges в HTTP-запросах)…
-[[Зображення:algorithm_c.jpg]]
+В конфигурации с использованием nginx как frontend-сервера, Вы имеете возможность создать простое правило для переписывания ссылок в запросах так, чтобы все красивые ссылки типа http://your.cool-service.com/files/cool.mp3 автоматически направлялись на некоторый скрипт /down.php и, если он вернет заголовок X-Accel-Redirect, файл автоматически отдавался клиенту с поддержкой Ranges и всех остальных прелестей раздачи статического контента с frontend-сервера. Backend-сервер в это время сможет обрабатывать другие запросы. Ваши пользователи могут даже не знать о том, что их закачки контролируются Вами. Примерная диаграмма описанного алгоритма приведена ниже:
-Позвольте обратить Ваше внимание на важный факт: Если Вам нужно только увеличение производительности работы сайта с помощью описанной здесь техники, и вы не хотите использовать систему контроля за скачиванием, то '''Вам не нужно ничено менять в скриптах на Вашем сервере!''' Они будут работать так же, как и раньше!
+<br> Позвольте обратить Ваше внимание на важный факт: Если Вам нужно только увеличение производительности работы сайта с помощью описанной здесь техники, и вы не хотите использовать систему контроля за скачиванием, то '''Вам не нужно ничено менять в скриптах на Вашем сервере!''' Они будут работать так же, как и раньше!
 Итак, последнее, чем я могу помочь Вам в тяжелом труде оптимизации использования ресурсов Вашего сервера, - это пример конфигурации для nginx, которая может быть использована Вами в качестве базовой при конфигурации Вашего сервера:
   server {
@@ Рядок 71: / Рядок 71: @@
+     }
-Полная версия конфигурационного файла лежит [http://wiki.energy-service.com.ua/wiki//src/rproxy-boost.nginx.conf | здесь] или  [http://blog.kovyrin.net/files/nginx-conf/rproxy-boost.nginx.conf | здесь].
+Полная версия конфигурационного файла лежит [http://wiki.energy-service.com.ua/wiki//src/rproxy-boost.nginx.conf | здесь] или [http://blog.kovyrin.net/files/nginx-conf/rproxy-boost.nginx.conf | здесь].
 Замечание: Если скрипты на Вашем backend-сервере используют IP-адреса клиентов в каких-то целях, то Вам необходимо установить на сервер модуль mod_rpaf module, чтобы он использовал передаваемый nginx заголовок X-Real-IP в качестве основного адреса пользователя.
 Вот и все! Теперь Вы можете установить себе на сервер nginx, отконфигурировать его и получить возможность обслуживать большее количество клиентов при использовании меньшего количества ресурсов! Все будет работать абсолютно прозрачно для уже написанных скриптов и, если хотите, Вы сможете организивать контролируемое скачивание при помощи метода, который я опишу в одном из следующих постов.
 Если у Вас есть какие-либо вопросы, задавайте их в комментариях не откладывая - я попробую ответить на них. Если эта статья понравилась Вам, можете обратить внимание на рекламные объявления на этой стратице или просто проголосуйте за нее на Digg.com.

@@ Рядок 71: / Рядок 71: @@
+     }
-Полная версия конфигурационного файла лежит [ http://wiki.energy-service.com.ua/wiki//src/rproxy-boost.nginx.conf | здесь] или  [http://blog.kovyrin.net/files/nginx-conf/rproxy-boost.nginx.conf | здесь].
+Полная версия конфигурационного файла лежит [http://wiki.energy-service.com.ua/wiki//src/rproxy-boost.nginx.conf | здесь] или  [http://blog.kovyrin.net/files/nginx-conf/rproxy-boost.nginx.conf | здесь].
 Замечание: Если скрипты на Вашем backend-сервере используют IP-адреса клиентов в каких-то целях, то Вам необходимо установить на сервер модуль mod_rpaf module, чтобы он использовал передаваемый nginx заголовок X-Real-IP в качестве основного адреса пользователя.

@@ Рядок 71: / Рядок 71: @@
+     }
-Полная версия конфигурационного файла лежит [ http://wiki.energy-service.com.ua/wiki//src/rproxy-boost.nginx.conf / здесь] или  [http://blog.kovyrin.net/files/nginx-conf/rproxy-boost.nginx.conf | здесь].
+Полная версия конфигурационного файла лежит [ http://wiki.energy-service.com.ua/wiki//src/rproxy-boost.nginx.conf | здесь] или  [http://blog.kovyrin.net/files/nginx-conf/rproxy-boost.nginx.conf | здесь].
 Замечание: Если скрипты на Вашем backend-сервере используют IP-адреса клиентов в каких-то целях, то Вам необходимо установить на сервер модуль mod_rpaf module, чтобы он использовал передаваемый nginx заголовок X-Real-IP в качестве основного адреса пользователя.

@@ Рядок 71: / Рядок 71: @@
+     }
-Полная версия конфигурационного файла лежит [http://blog.kovyrin.net/files/nginx-conf/rproxy-boost.nginx.conf | здесь].
+Полная версия конфигурационного файла лежит [ http://wiki.energy-service.com.ua/wiki//src/rproxy-boost.nginx.conf / здесь] или  [http://blog.kovyrin.net/files/nginx-conf/rproxy-boost.nginx.conf | здесь].
 Замечание: Если скрипты на Вашем backend-сервере используют IP-адреса клиентов в каких-то целях, то Вам необходимо установить на сервер модуль mod_rpaf module, чтобы он использовал передаваемый nginx заголовок X-Real-IP в качестве основного адреса пользователя.

← Попередня версія		Версія за 10:02, 25 березня 2009
Рядок 27:		Рядок 27:
	В конфигурации с использованием nginx как frontend-сервера, Вы имеете возможность создать простое правило для переписывания ссылок в запросах так, чтобы все красивые ссылки типа http://your.cool-service.com/files/cool.mp3 автоматически направлялись на некоторый скрипт /down.php и, если он вернет заголовок X-Accel-Redirect, файл автоматически отдавался клиенту с поддержкой Ranges и всех остальных прелестей раздачи статического контента с frontend-сервера. Backend-сервер в это время сможет обрабатывать другие запросы. Ваши пользователи могут даже не знать о том, что их закачки контролируются Вами. Примерная диаграмма описанного алгоритма приведена ниже:		В конфигурации с использованием nginx как frontend-сервера, Вы имеете возможность создать простое правило для переписывания ссылок в запросах так, чтобы все красивые ссылки типа http://your.cool-service.com/files/cool.mp3 автоматически направлялись на некоторый скрипт /down.php и, если он вернет заголовок X-Accel-Redirect, файл автоматически отдавался клиенту с поддержкой Ranges и всех остальных прелестей раздачи статического контента с frontend-сервера. Backend-сервер в это время сможет обрабатывать другие запросы. Ваши пользователи могут даже не знать о том, что их закачки контролируются Вами. Примерная диаграмма описанного алгоритма приведена ниже:

−	[[Зображення:algorithm_c.~~png~~]]	+	[[Зображення:algorithm_c.jpg]]