Статья (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.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=7539
Не круто. Сегодня трабл в тяжлелых беках, а не в медленных клиентах.Бекенд - что угодно: апач, лайт, нжынкс, которые ворочают приложения.
Нжынкс и лайт на ПХП могут оказаться СИЛЬНО быстрее апачаА вот фронт - сысоевский же mod_accel с выставленными "кешировать ВСЕ (за разумным исключением) и НАВСЕГДА".
Первый клиент вносит станицу в кеш mod_accel'я, остальные 15000 получают ее со скоростью света не трогая SQL.
Вот это будет реальное ускорение и, что важнее, рост нагрузочной способности сервера. Так это от 10 раз. А в смысле нагрузочной способности и до 1000 раз по сравнению с описанной "двуслойкой".
Обновление контента скриптиком - апачктл стоп рм дерево кеша криейт дерево кеша апачктл старт. Причем если бекенд умер - самые популярные страницы (запрошенные больше одного нуля раз :) будут сдаваться аккселем, как новенькие :)
Так вы батенька забудьте про статические HTML-страницы...редкость уже давно,
годится только для тех, кто только select иногда в базу делает
а что делать движкам форумным?
>Так вы батенька забудьте про статические HTML-страницы...редкость уже давно,
>годится только для тех, кто только select иногда в базу делает
>а что делать движкам форумным?90% процентов CMS, формов и прочего веб-софта написаны очень неоптимально с точки зрения производительности...
А на крцупных веб-порталах статики гораздо больше...
а делать select в базу на каждый запрос это дорого, и не всегда нужно.
Похожий подход используют в Wikipedia
Примерно как все продуктовые магазины похожи, потому что продают пиво.
что то вы как то путаетесь.> Сегодня трабл в тяжлелых беках, а не в медленных клиентах.
nginx как раз таки и нужен, чтоб изолировать медленных клиентов (а они думаю всегду будут медленне бэкендов), от тяжелых бэкендов. Чтоб бэкенд мог отдавать данные за минимально возможное время, а потом nginx медленно отдавал эти данные клиенту.
> Нжынкс и лайт на ПХП могут оказаться СИЛЬНО быстрее апача
в nginx нет встренной поддержки php. и не будет. Можно запустить php в режиме fastcgi (а запросы на fastcgi направлять через реверсный прокси, например nginx) только это не будет сильно быстрее mod_php. Вполне возможно будет даже медленне, чем mod_php+apc.
> А вот фронт - сысоевский же mod_accel с выставленными "кешировать ВСЕ (за разумным исключением) и НАВСЕГДА".
1. кэширование это хорошо, только mod_accel это тяжелый апач и от клиентов его все равно лучше прятать за ngix.
2. чаще кеширование удобно выполнять не на уровне http, а на уровне приложений - через memcached.
> кэширование это хорошо, только mod_accel это тяжелый апач и от клиентов его все равно лучше прятать за ngix.Вот это единственное здравое суждение в вашей дикой чуши, но только оно даст прирост силы в 0.1%
>> кэширование это хорошо, только mod_accel это тяжелый апач и от клиентов его все равно лучше прятать за ngix.
>
>Вот это единственное здравое суждение в вашей дикой чуши, но только оно
>даст прирост силы в 0.1%
И вообще. Есть такая фтуська, ПРАКТИКА называется.
То есть, сначала сделай, а потом трынди.
Но за искючением 1. Автора новости 2. Меня 3. Хольсера
потоки сознаний самовыражающихся тута практикой не страдают.
Зуб дадите? Двести апачей на десять болтающихся поменять -- это 0.1%?Трепло безымянное.
> Зуб дадите? Двести апачей на десять болтающихся поменять -- это 0.1%?Да. У меня 8 ядер в 4 гигах озу. Мне до лампочки глубоко миллион там апачей или 10 тыщ.
А вот бек - ТЯЖЕЛЫЙ.
>2. чаще кеширование удобно выполнять не на уровне http, а на уровне
>приложений - через memcached.А на уровне написания пропертиарной ОС ничего не надо? Совсем ничего? Нет?
А то еще можно новый проц изобрести... Или хрустальный мост с голыми девушками на бензиновом приводе...
>Какие-то костыльно-кувалдные у Вас подходы, батенька. Для моих нагрузок хватает как
>раз nginx+apache и мультикэширующей CMS (в принципе, оно и static export
>умеет, но не требуется), а вот с таким вебмастером на одной
>зоне ответственности работать бы поостерёгся.А вот у меня CMS пропертиарная. С КРАЙНЕ интенсивным объемом вычислений на беке.
Посоветуйте дуракам, загружающим Ёс Симулятор, "мультикэширующий CMS",
"изначально задумывать оптимизацию" и "сразу задачу нормально"
>А вот у меня CMS пропертиарная.
ССЗБ. И писать учитесь :)
Движкам форумным - лайт с удаленным фаст-сижиаем. Можно прокисровать нжынксом, можно не проксировать - плюс-минус полпроцента.
Поверьте мне, как специалисту, это похоже на создание формулы 1 из Запорожца. Если изначально не задумывалась оптимизация (а о ней почему то думают в самый последний момент), но ни какой nginx не поможет. Я видел очень грамотные сайты написанные с использованием Java и в качестве сервера jBoss, которые выдавали 1000 запросов к базе в секунду, и запросы не просто Select, в целом не создавая нагрузку на frontend сервер. Я проверил и статика составлят 5%, в основном картинки, а основную нагрузку создает SQL сервер, вот здесь и поле для оптимизации. В данном контретном случае все закончилось созданием MySQL EMIC кластера, в конечном счете обошлось дешевле исли бы 2 программиста оптимизировали и затачивали код. Лицензия покупалась у continuent.com. Но самый главный вывод, все должно расматриваться с точке рентабельности. Если мне прийдется заплатить 10k за работу и ждать результата год, тогда лучше купить железо и создать кластер.
2Holser: а не проще сразу задачу нормально поставить?
2Vaso Petrovich, все меняется... и нужно соотвествовать текущим задачам.
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!
Хм..апач на обработку одного запроса использует один процесс.
Вырожденный случай (но реальный) - клиенты скачивают большие файлы по http. Если одновременных клиентов 1000 - то процессов апача будет 1000 как минимум, а они тяжелые. Они будут висеть, пока клиенты качают. Тут, думаю, выгода от выделения frontend-сервера очевидна.
Другой пример - всегда есть достаточно много статики. Картинки, цсс, яваскрипты. И этой статики будет всегда дофига. Для нее выгода от nginx так же очевидна.
Что касается динамики. Да, кешировать всю динамику глупо. Ну и что? Самостоятельно разрабатывать кеширующий слой обычно дороже. По крайней мере, он не замедлит работу, а в случае, когда вам не нужно порождать дополнительные апачевские процессы за счет выигрыша в остальном - только поможет.
Так что, в случае LAMP - имеет смысл использовать nginx если проект отличается от "Газеты вечерний Вуглускр".
Лично по моему опыту - могу сказать, что получил выигрыш около 70% (!) Статики при этом совсем немного.
Victor Kuriashkin
>Вырожденный случай (но реальный) - клиенты скачивают большие файлы по http. Если
>одновременных клиентов 1000 - то процессов апача будет 1000 как минимум,
>а они тяжелые. Они будут висеть, пока клиенты качают. Тут, думаю,
>выгода от выделения frontend-сервера очевидна.Тут как раз очевидна выгода от выделенного под статику шустрого простого сервера и неиспользования для неё apache вообще :) Будь это виртхост или /download.
>Лично по моему опыту - могу сказать, что получил выигрыш около 70%
>(!) Статики при этом совсем немного.Очень сильно помогает на "висяках" память экономить -- браузер ещё сидит на keepalive, но уже ничего не спросит [какое-то время].