The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"OpenNews: Оптимизация работы веб-сервера при помощи reverse-..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [Проследить за развитием треда]

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

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

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


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

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Оптимизация работы веб-сервера при помощи reverse-proxy"  
Сообщение от johnjoy (??) on 18-Май-06, 19:54 
Похожий подход используют в Wikipedia
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

5. "Оптимизация работы веб-сервера при помощи reverse-proxy"  
Сообщение от citrin email(ok) on 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.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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


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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "ну раз проприетарная..."  
Сообщение от gvy email on 19-Май-06, 19:41 
>А вот у меня CMS пропертиарная.
ССЗБ.  И писать учитесь :)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

9. "Оптимизация работы веб-сервера при помощи reverse-proxy"  
Сообщение от Vaso Petrovich on 19-Май-06, 09:17 
2Holser: а не проще сразу задачу нормально поставить?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Оптимизация работы веб-сервера при помощи reverse-proxy"  
Сообщение от Doktor (??) on 19-Май-06, 13:03 
2Vaso Petrovich, все меняется... и нужно соотвествовать текущим задачам.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "Оптимизация работы веб-сервера при помощи reverse-proxy"  
Сообщение от edgars (??) on 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!
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

Victor Kuriashkin

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру