The OpenNET Project / Index page

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

Оптимизация работы веб-сервера при помощи reverse-proxy

18.05.2006 16:23

Статья о том, как построить стабильный и эффективный веб-сервер с двухуровневой архитектурой обработки запросов (с двумя веб-серверами: frontend (nginx) и backend) и о том, как модифицировать Ваш текущий сервер, чтобы получить дополнительные ресурсы для обработки большего количества запросов.

  1. Главная ссылка к новости (http://blog.kovyrin.net/2006/0...)
Автор новости: Alexey N. Kovyrin
Тип: яз. русский / Практикум
Короткая ссылка: https://opennet.ru/7539-nginx
Ключевые слова: nginx, web, speed, apache, balance, proxy
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (20) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 17:55, 18/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не круто. Сегодня трабл в тяжлелых беках, а не в медленных клиентах.

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

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

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

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

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

     
     
  • 2.2, alrond (??), 18:31, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Так вы батенька забудьте про статические HTML-страницы...редкость уже давно,
    годится только для тех, кто только select иногда в базу делает
    а что делать движкам форумным?
     
     
  • 3.6, citrin (ok), 20:04, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Так вы батенька забудьте про статические HTML-страницы...редкость уже давно,
    >годится только для тех, кто только select иногда в базу делает
    >а что делать движкам форумным?

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

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

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

     
  • 2.4, johnjoy (??), 19:54, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Похожий подход используют в Wikipedia
     
     
  • 3.7, Анатолий Стояновский (?), 23:39, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Примерно как все продуктовые магазины похожи, потому что продают пиво.
     
  • 2.5, citrin (ok), 20:01, 18/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    что то вы как то путаетесь.

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

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

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

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

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

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

     
     
  • 3.10, Аноним (-), 09:56, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > кэширование это хорошо, только mod_accel это тяжелый апач и от клиентов его все равно лучше прятать за ngix.

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

     
     
  • 4.11, Аноним (-), 09:59, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >> кэширование это хорошо, только mod_accel это тяжелый апач и от клиентов его все равно лучше прятать за ngix.
    >
    >Вот это единственное здравое суждение в вашей дикой чуши, но только оно
    >даст прирост силы в 0.1%


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

     
  • 4.13, gvy (?), 12:25, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Зуб дадите?  Двести апачей на десять болтающихся поменять -- это 0.1%?

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

     
     
  • 5.14, Аноним (-), 12:52, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > Зуб дадите?  Двести апачей на десять болтающихся поменять -- это 0.1%?

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

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

     
  • 3.15, Аноним (-), 12:58, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >2. чаще кеширование удобно выполнять не на уровне http, а на уровне
    >приложений - через memcached.

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

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

     
  • 3.17, Аноним (-), 13:04, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Какие-то костыльно-кувалдные у Вас подходы, батенька.  Для моих нагрузок хватает как
    >раз nginx+apache и мультикэширующей CMS (в принципе, оно и static export
    >умеет, но не требуется), а вот с таким вебмастером на одной
    >зоне ответственности работать бы поостерёгся.

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

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

     
     
  • 4.19, gvy (?), 19:41, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >А вот у меня CMS пропертиарная.
    ССЗБ.  И писать учитесь :)
     

  • 1.3, Аноним (-), 18:48, 18/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Движкам форумным - лайт с удаленным фаст-сижиаем. Можно прокисровать нжынксом, можно не проксировать - плюс-минус полпроцента.
     
  • 1.8, Holser (?), 02:02, 19/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Поверьте мне, как специалисту, это похоже на создание формулы 1 из Запорожца. Если изначально не задумывалась оптимизация (а о ней почему то думают в самый последний момент), но ни какой nginx не поможет. Я видел очень грамотные сайты написанные с использованием Java и в качестве сервера jBoss, которые выдавали 1000 запросов к базе в секунду, и запросы не просто Select, в целом не создавая нагрузку на frontend сервер. Я проверил и статика составлят 5%, в основном картинки, а основную нагрузку создает SQL сервер, вот здесь и поле для оптимизации. В данном контретном случае все закончилось созданием MySQL EMIC кластера, в конечном счете обошлось дешевле исли бы 2 программиста оптимизировали и затачивали код. Лицензия покупалась у continuent.com. Но самый главный вывод, все должно расматриваться с точке рентабельности. Если мне прийдется заплатить 10k за работу и ждать результата год, тогда лучше купить железо и создать кластер.
     
     
  • 2.9, Vaso Petrovich (?), 09:17, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    2Holser: а не проще сразу задачу нормально поставить?
     

  • 1.16, Doktor (??), 13:03, 19/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    2Vaso Petrovich, все меняется... и нужно соотвествовать текущим задачам.
     
  • 1.18, edgars (??), 19:38, 19/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    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!
     
  • 1.21, Виктор Куряшкин (?), 03:04, 01/11/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хм..

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

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

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

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

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

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

    Victor Kuriashkin

     
     
  • 2.22, Michael Shigorin (ok), 09:42, 01/11/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Вырожденный случай (но реальный) - клиенты скачивают большие файлы по http. Если
    >одновременных клиентов 1000 - то процессов апача будет 1000 как минимум,
    >а они тяжелые. Они будут висеть, пока клиенты качают. Тут, думаю,
    >выгода от выделения frontend-сервера очевидна.

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

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

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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