Використання Nginx Як Reverse-Proxy Сервера На Завантажених Веб-сайтах (web nginx http proxy apache)
Ключові слова: web

, nginx , http , proxy , apache , ( знайти схожі документи )
From: Alexey N. Kovyrin < [email protected]. > Date: Sun, 18 Sep 2007 17:02:14 +0000 (UTC) Subject: Використання Nginx Як Reverse-Proxy Сервера На Завантажених Сайтах Оригінал: http://blog.kovyrin.net/2006/05/18/nginx-as-reverse-proxy/lang/ru/ Два тижні тому ми запустили нову версію одного з наших ОСНОВНІ веб-проектів і почали масивну рекламну підтримку цього сайту. В результаті реклами, вихідний трафік тільки з одного сервера досяг 200-250Mbit / s! У даній статті я опишу, як побудувати стабільний і ефективний веб-сайт з дворівневої архітектурою обробки запитів (з двома веб-серверами: frontend і backend) або як модифікувати ваш поточний сервер, щоб отримати додаткові ресурси для обробки більшої кількості запитів. Для початку, опишу типовий процес обслуговування запиту до веб-сервера і структуру самого сервера: 1. Клієнт ініціює запит до сервера. 2. Його браузер встановлює з'єднання з сервером. 3. Ваш сервер (наприклад, Apache) створює новий потік / процес для обробки запиту. 4. Якщо клієнт запросив динамічний контент (наприклад, відправив запит до php-скрипту), веб-сервер створює окремий CGI-процес або запускає модуль обробки скриптів (наприклад, mod_php) і чекає, поки запит буде оброблений. Як тільки він отримує результуючу web-сторінку, то вона відправляється клієнтові. 5. Якщо ж клієнт запросив статичний файл, то сервер просто відправляє цей файл клієнтові. 6. Браузер клієнта отримує відповідь, закриває з'єднання з сервером і відображає "відповідь". Як бачите, якщо до сервера приходить дуже багато запитів, він повинен створювати багато паралельних потоків / процесів і тримати їх в пам'яті, поки покупець не закриє з'єднання. Якщо з'єднання у клієнта не швидка, то серверні процеси будуть висіти в пам'яті досить довго і використовувані ними ресурси будуть збільшуватися дуже швидко. Як же вирішити цю проблему? Простим рішенням може бути нескінченна збільшення обсягів оперативної пам'яті на сервері і покупка додаткових або більш потужних процесорів в очікуванні моменту, коли сервер помре під навантаженням ... Але існує більш ефективне рішення! Ви можете просто помістити невелику програмку (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-сервер в цей час зможе обробляти інші запити. Ваші користувачі можуть навіть не знати про те, що їх закачування контролюються Вами. Дозвольте звернути Вашу увагу на важливий факт: Якщо Вам потрібно тільки збільшення продуктивності роботи сайту за допомогою описаної тут техніки, і ви не хочете використовувати систему контролю за скачуванням, то Вам не потрібно нічено міняти в скриптах на Вашому сервері! Вони будуть працювати так само, як і раніше! Отже, останнє, чим я можу допомогти Вам у важкій праці оптимізації використання ресурсів Вашого сервера, - це приклад конфігурації для nginx, яка може бути використана Вами в якості базової при конфігурації Вашого сервера: server {listen 80; server_name some-server.com www.server-name.com; access_log logs / host.access.log main; # Main location location / {proxy_pass http://127.0.0.1 : 8080 /; proxy_redirect off; proxy_set_header Host $ host; proxy_set_header X-Real-IP $ remote_addr; proxy_set_header X-Forwarded-For $ proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; } # Static files location location ~ * ^. +. (Jpg | jpeg | gif | png | ico | css | zip | tgz | gz | rar | bz2 | doc | xls | exe | pdf | ppt | txt | tar | mid | midi | wav | bmp | rtf | js) $ {root / spool / www / members_ng; }} Повна версія конфігураційного файлу лежить тут. Зауваження: Якщо скрипти на Вашому backend-сервері використовують IP-адреси клієнтів в якихось цілях, то Вам необхідно встановити на сервер модуль mod_rpaf module, щоб він використовував передається nginx заголовок X-Real-IP в якості основного адреси користувача. От і все! Тепер Ви можете встановити собі на сервер nginx, отконфигурировать його і отримати можливість обслуговувати більшу кількість клієнтів при використанні меншої кількості ресурсів! Все буде працювати абсолютно прозоро для вже написаних скриптів і, якщо хочете, Ви зможете організівать контрольоване скачування за допомогою методу, який я опишу в одному з наступних постів. ;-)

Обговорення [ RSS ]

• 2 , Serj (??), 19:32, 03/12/2009 [ відповісти ]

+

/ - client_max_body_size 10m;
client_body_buffer_size 128k;

proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;

proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;

Ці зачнія взагалі обезательно? А то читав на Сисоєва про них все, не зрозумів що краще ставити їх в якомусь визначенні або буде краще ніж їх немає прописаних в конфіги ..

Додати коментар

Спонсори:

Хостинг: