форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (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 (??) on 18-Май-06, 18:31
	Так вы батенька забудьте про статические HTML-страницы...редкость уже давно, годится только для тех, кто только select иногда в базу делает а что делать движкам форумным?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Оптимизация работы веб-сервера при помощи reverse-proxy"
	Сообщение от citrin (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 (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 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 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 (ok) on 01-Ноя-07, 09:42
	>Вырожденный случай (но реальный) - клиенты скачивают большие файлы по http. Если >одновременных клиентов 1000 - то процессов апача будет 1000 как минимум, >а они тяжелые. Они будут висеть, пока клиенты качают. Тут, думаю, >выгода от выделения frontend-сервера очевидна. Тут как раз очевидна выгода от выделенного под статику шустрого простого сервера и неиспользования для неё apache вообще :)  Будь это виртхост или /download. >Лично по моему опыту - могу сказать, что получил выигрыш около 70% >(!) Статики при этом совсем немного. Очень сильно помогает на "висяках" память экономить -- браузер ещё сидит на keepalive, но уже ничего не спросит [какое-то время].
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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