URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 15438
[ Назад ]

Исходное сообщение
"OpenNews: Оптимизация работы веб-сервера при помощи reverse-proxy"

Отправлено opennews , 18-Май-06 17:55 
Статья (http://blog.kovyrin.net/2006/05/18/nginx-as-reverse-proxy/la.../) о том, как построить стабильный и эффективный веб-сервер с двухуровневой архитектурой обработки запросов (с двумя веб-серверами: frontend (nginx) и backend) и о том, как модифицировать Ваш текущий сервер, чтобы получить дополнительные ресурсы для обработки большего количества запросов.

URL: http://blog.kovyrin.net/2006/05/18/nginx-as-reverse-proxy/la.../
Новость: http://www.opennet.me/opennews/art.shtml?num=7539


Содержание

Сообщения в этом обсуждении
"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено Аноним , 18-Май-06 17:55 
Не круто. Сегодня трабл в тяжлелых беках, а не в медленных клиентах.

Бекенд - что угодно: апач, лайт, нжынкс, которые ворочают приложения.
Нжынкс и лайт на ПХП могут оказаться СИЛЬНО быстрее апача

А вот фронт - сысоевский же mod_accel с выставленными "кешировать ВСЕ (за разумным исключением) и НАВСЕГДА".

Первый клиент вносит станицу в кеш mod_accel'я, остальные 15000 получают ее со скоростью света не трогая SQL.

Вот это будет реальное ускорение и, что важнее, рост нагрузочной способности сервера. Так это от 10 раз. А в смысле нагрузочной способности и до 1000 раз по сравнению с описанной "двуслойкой".

Обновление контента скриптиком - апачктл стоп рм дерево кеша криейт дерево кеша апачктл старт. Причем если бекенд умер - самые популярные страницы (запрошенные больше одного нуля раз :) будут сдаваться аккселем, как новенькие :)


"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено alrond , 18-Май-06 18:31 
Так вы батенька забудьте про статические HTML-страницы...редкость уже давно,
годится только для тех, кто только select иногда в базу делает
а что делать движкам форумным?

"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено citrin , 18-Май-06 20:04 
>Так вы батенька забудьте про статические HTML-страницы...редкость уже давно,
>годится только для тех, кто только select иногда в базу делает
>а что делать движкам форумным?

90% процентов CMS, формов и прочего веб-софта написаны очень неоптимально с точки зрения производительности...

А на крцупных веб-порталах статики гораздо больше...

а делать select в базу на каждый запрос это дорого, и не всегда нужно.


"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено johnjoy , 18-Май-06 19:54 
Похожий подход используют в Wikipedia

"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено Анатолий Стояновский , 18-Май-06 23:39 
Примерно как все продуктовые магазины похожи, потому что продают пиво.

"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено citrin , 18-Май-06 20:01 
что то вы как то путаетесь.

> Сегодня трабл в тяжлелых беках, а не в медленных клиентах.

nginx как раз таки и нужен, чтоб изолировать медленных клиентов (а они думаю всегду будут медленне бэкендов), от тяжелых бэкендов. Чтоб бэкенд мог отдавать данные за минимально возможное время, а потом nginx медленно отдавал эти данные клиенту.

> Нжынкс и лайт на ПХП могут оказаться СИЛЬНО быстрее апача

в nginx нет встренной поддержки php. и не будет. Можно запустить php в режиме fastcgi (а запросы на fastcgi направлять через реверсный прокси, например nginx) только это не будет сильно быстрее mod_php. Вполне возможно будет даже медленне, чем mod_php+apc.

> А вот фронт - сысоевский же mod_accel с выставленными "кешировать ВСЕ (за разумным исключением) и НАВСЕГДА".

1. кэширование это хорошо, только mod_accel это тяжелый апач и от клиентов его все равно лучше прятать за ngix.
2. чаще кеширование удобно выполнять не на уровне http, а на уровне приложений - через memcached.


"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено Аноним , 19-Май-06 09:56 
> кэширование это хорошо, только mod_accel это тяжелый апач и от клиентов его все равно лучше прятать за ngix.

Вот это единственное здравое суждение в вашей дикой чуши, но только оно даст прирост силы в 0.1%


"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено Аноним , 19-Май-06 09:59 
>> кэширование это хорошо, только mod_accel это тяжелый апач и от клиентов его все равно лучше прятать за ngix.
>
>Вот это единственное здравое суждение в вашей дикой чуши, но только оно
>даст прирост силы в 0.1%


И вообще. Есть такая фтуська, ПРАКТИКА называется.
То есть, сначала сделай, а потом трынди.
Но за искючением 1. Автора новости 2. Меня 3. Хольсера
потоки сознаний самовыражающихся тута практикой не страдают.


"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено gvy , 19-Май-06 12:25 
Зуб дадите?  Двести апачей на десять болтающихся поменять -- это 0.1%?

Трепло безымянное.


"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено Аноним , 19-Май-06 12:52 
> Зуб дадите?  Двести апачей на десять болтающихся поменять -- это 0.1%?

Да. У меня 8 ядер в 4 гигах озу. Мне до лампочки глубоко миллион там апачей или 10 тыщ.

А вот бек - ТЯЖЕЛЫЙ.


"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено Аноним , 19-Май-06 12:58 
>2. чаще кеширование удобно выполнять не на уровне http, а на уровне
>приложений - через memcached.

А на уровне написания пропертиарной ОС ничего не надо? Совсем ничего? Нет?

А то еще можно новый проц изобрести... Или хрустальный мост с голыми девушками на бензиновом приводе...


"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено Аноним , 19-Май-06 13:04 
>Какие-то костыльно-кувалдные у Вас подходы, батенька.  Для моих нагрузок хватает как
>раз nginx+apache и мультикэширующей CMS (в принципе, оно и static export
>умеет, но не требуется), а вот с таким вебмастером на одной
>зоне ответственности работать бы поостерёгся.

А вот у меня CMS пропертиарная. С КРАЙНЕ интенсивным объемом вычислений на беке.

Посоветуйте дуракам, загружающим Ёс Симулятор, "мультикэширующий CMS",
"изначально задумывать оптимизацию" и "сразу задачу нормально"


"ну раз проприетарная..."
Отправлено gvy , 19-Май-06 19:41 
>А вот у меня CMS пропертиарная.
ССЗБ.  И писать учитесь :)

"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено Аноним , 18-Май-06 18:48 
Движкам форумным - лайт с удаленным фаст-сижиаем. Можно прокисровать нжынксом, можно не проксировать - плюс-минус полпроцента.

"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено Holser , 19-Май-06 02:02 
Поверьте мне, как специалисту, это похоже на создание формулы 1 из Запорожца. Если изначально не задумывалась оптимизация (а о ней почему то думают в самый последний момент), но ни какой nginx не поможет. Я видел очень грамотные сайты написанные с использованием Java и в качестве сервера jBoss, которые выдавали 1000 запросов к базе в секунду, и запросы не просто Select, в целом не создавая нагрузку на frontend сервер. Я проверил и статика составлят 5%, в основном картинки, а основную нагрузку создает SQL сервер, вот здесь и поле для оптимизации. В данном контретном случае все закончилось созданием MySQL EMIC кластера, в конечном счете обошлось дешевле исли бы 2 программиста оптимизировали и затачивали код. Лицензия покупалась у continuent.com. Но самый главный вывод, все должно расматриваться с точке рентабельности. Если мне прийдется заплатить 10k за работу и ждать результата год, тогда лучше купить железо и создать кластер.

"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено Vaso Petrovich , 19-Май-06 09:17 
2Holser: а не проще сразу задачу нормально поставить?

"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено Doktor , 19-Май-06 13:03 
2Vaso Petrovich, все меняется... и нужно соотвествовать текущим задачам.

"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено edgars , 19-Май-06 19:38 
horosho tak, a vot tak tufta, a vot ja by zdelal tak i poluchili by vse 500% uskorenija. Tak davaite pokazhite pozhaluisto vash manual/howto da vsjoravno shto, no rabotosposobnoje, a to besit vot takuju chush chitacj!

"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено Виктор Куряшкин , 01-Ноя-07 03:04 
Хм..

апач на обработку одного запроса использует один процесс.

Вырожденный случай (но реальный) - клиенты скачивают большие файлы по http. Если одновременных клиентов 1000 - то процессов апача будет 1000 как минимум, а они тяжелые. Они будут висеть, пока клиенты качают. Тут, думаю, выгода от выделения frontend-сервера очевидна.  

Другой пример - всегда есть достаточно много статики. Картинки, цсс, яваскрипты. И этой статики будет всегда дофига. Для нее выгода от nginx так же очевидна.

Что касается динамики. Да, кешировать всю динамику глупо. Ну и что? Самостоятельно разрабатывать кеширующий слой обычно дороже. По крайней мере, он не замедлит работу, а в случае, когда вам не нужно порождать дополнительные апачевские процессы за счет выигрыша в остальном - только поможет.

Так что, в случае LAMP - имеет смысл использовать nginx если проект отличается от "Газеты вечерний Вуглускр".

Лично по моему опыту - могу сказать, что получил выигрыш около 70% (!) Статики при этом совсем немного.

Victor Kuriashkin


"Оптимизация работы веб-сервера при помощи reverse-proxy"
Отправлено Michael Shigorin , 01-Ноя-07 09:42 
>Вырожденный случай (но реальный) - клиенты скачивают большие файлы по http. Если
>одновременных клиентов 1000 - то процессов апача будет 1000 как минимум,
>а они тяжелые. Они будут висеть, пока клиенты качают. Тут, думаю,
>выгода от выделения frontend-сервера очевидна.

Тут как раз очевидна выгода от выделенного под статику шустрого простого сервера и неиспользования для неё apache вообще :)  Будь это виртхост или /download.

>Лично по моему опыту - могу сказать, что получил выигрыш около 70%
>(!) Статики при этом совсем немного.

Очень сильно помогает на "висяках" память экономить -- браузер ещё сидит на keepalive, но уже ничего не спросит [какое-то время].