Под лж-катом — красивая картинка внутренней сетки ЖЖ (как устроены все сервера и как они между собой общаются). Если что-то непонятно или интересно, можно спрашивать.
Не знаю, а чем он так лучше mod_proxy? Я с ним не знаком, но вот сейчас посмотрел немного - все его улучшения типа busy locks или ограничения числа подключений нам не нужны. У нас главное именно load balancing бэкенда, а он в этом смысле ничего нового не даёт.
Вот умеет ли он делать transparent redirect? Скажем, если бэкенд возвращает 301 (или какой-то кастомный код, неважно), он не пересылает его юзеру, а сам внутри идёт по новому адресу, берёт оттуда то, что надо, и посылает юзеру как ответ на первоначальный запрос? Вот такая штука нам нужна, а mod_proxy её не поддерживает; если не найдём что-то готовое, я буду в mod_proxy это добавлять.
rewrite balancer - использует что-то вроде mod_backhand, но не сам mod_backhand, он нам не подходил. На веб-серверах бежит модуль Apache::SendStats (custom, тоже мной написан), который броадкастит в UDP количество свободных детей данного сервера в конце каждого запроса. rewrite balancer-ы, бегущие на машинах mod_proxy, слушают эту статистику и выбирают для передачи mod_rewrite один из свободных серверов по weighted average.
(вместо броадкаста надо, наверное, по-хорошему сделать мультикаст, но мы не собрались пока).
>> У нас главное именно load balancing бэкенда, а он в этом смысле ничего нового не даёт.
Очень даже дает. Тут (http://sysoev.ru/mod_accel/readme.html#mod_proxy) есть описание, в чем mod_proxy лажает при работе с backend'ом.
Возможностей performance tuning'а гораздо больше чем с mod_proxy. Опять же хорошо обрабатывает авторизацию по cookies и можно тонко управлять expires.
В тему - с mod_deflate же контент очень хорошо жмется (автор тот же). Все pitfalls учтены.
Насчет transparent redirect - самому надо. В mod_accel есть hook - note "accel_rewrite_response". Т.о. пишется нехитрый модуль и все. Лично у меня руки как-то не доходят.
Мы внимательно посмотрим на mod_accel и, возможно, будем пользоваться именно им. Я действительно не знал о недостатках mod_proxy в вопросе ускорения бэкенда.
Как уже было замечено, для транспарент редиректа можно использовать accel_rewrite_response - в обработчике делать sub_request.
Примитивный (на основе dns) load-balancing и fault-tolerance есть. Более умный можно прикрутить через hook open_backend.
Можно кэшировать ответ с учётом куки, то есть, обычные и залогиненые пользователи получат разные ответы. Не знаю, правда, даст ли что-нибудь в вашем случае кэширование.
В общем, вопросы - welcome.
Но должен заметить, что mod_accel - это вчерашний день. Я сейчас пишу веб и прокси-сервер, который работает на select/kqueue/etc Так вот, там будет фич по-более посравнению с mod_accel.
Большое спасибо. Я, видимо, буду пристально изучать mod_accel на следующей неделе. Если будут вопросы, напишу.
Кэширование в нашем случае бесполезно. Очень важна совместимость с mod_rewrite, но, насколько я понял, она есть.
Веб-сервер мы вряд ли будем менять, т.к. основная работа у нас происходит в Перле, и всё завязано на mod_perl ;)
Если Вы пишете аппликации на select/kqueue, возможно, стоит взглянуть на epoll (select в Линуксе начинает тормозить с большим количеством подключений). Есть неплохая библиотека libevent, которая абстрагирует разные методы оповещения в общий интерфейс; я воспользовался ей при написании memcached, которым мы сейчас пользуемся в больших масштабах.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2003-11-11 07:46 am (UTC)а rewrite/load balancer - просто тупо по кругу выдает очередной сервер или используется что-то вроде mod_backhand?
no subject
Date: 2003-11-11 08:04 am (UTC)Вот умеет ли он делать transparent redirect? Скажем, если бэкенд возвращает 301 (или какой-то кастомный код, неважно), он не пересылает его юзеру, а сам внутри идёт по новому адресу, берёт оттуда то, что надо, и посылает юзеру как ответ на первоначальный запрос? Вот такая штука нам нужна, а mod_proxy её не поддерживает; если не найдём что-то готовое, я буду в mod_proxy это добавлять.
rewrite balancer - использует что-то вроде mod_backhand, но не сам mod_backhand, он нам не подходил. На веб-серверах бежит модуль Apache::SendStats (custom, тоже мной написан), который броадкастит в UDP количество свободных детей данного сервера в конце каждого запроса. rewrite balancer-ы, бегущие на машинах mod_proxy, слушают эту статистику и выбирают для передачи mod_rewrite один из свободных серверов по weighted average.
(вместо броадкаста надо, наверное, по-хорошему сделать мультикаст, но мы не собрались пока).
no subject
Date: 2003-11-11 08:30 am (UTC)Очень даже дает. Тут (http://sysoev.ru/mod_accel/readme.html#mod_proxy) есть описание, в чем mod_proxy лажает при работе с backend'ом.
Возможностей performance tuning'а гораздо больше чем с mod_proxy. Опять же хорошо обрабатывает авторизацию по cookies и можно тонко управлять expires.
В тему - с mod_deflate же контент очень хорошо жмется (автор тот же). Все pitfalls учтены.
Насчет transparent redirect - самому надо. В mod_accel есть hook - note "accel_rewrite_response". Т.о. пишется нехитрый модуль и все. Лично у меня руки как-то не доходят.
no subject
Мы внимательно посмотрим на mod_accel и, возможно, будем пользоваться именно им. Я действительно не знал о недостатках mod_proxy в вопросе ускорения бэкенда.
no subject
Date: 2003-11-17 05:42 am (UTC)Примитивный (на основе dns) load-balancing и fault-tolerance есть. Более умный можно прикрутить через hook open_backend.
Можно кэшировать ответ с учётом куки, то есть, обычные и залогиненые пользователи получат разные ответы. Не знаю, правда, даст ли что-нибудь в вашем случае кэширование.
В общем, вопросы - welcome.
Но должен заметить, что mod_accel - это вчерашний день.
Я сейчас пишу веб и прокси-сервер, который работает на select/kqueue/etc
Так вот, там будет фич по-более посравнению с mod_accel.
no subject
Date: 2003-11-22 02:38 pm (UTC)Я, видимо, буду пристально изучать mod_accel на следующей неделе. Если будут вопросы, напишу.
Кэширование в нашем случае бесполезно. Очень важна совместимость с mod_rewrite, но, насколько я понял, она есть.
Веб-сервер мы вряд ли будем менять, т.к. основная работа у нас происходит в Перле, и всё завязано на mod_perl ;)
Если Вы пишете аппликации на select/kqueue, возможно, стоит взглянуть на epoll (select в Линуксе начинает тормозить с большим количеством подключений). Есть неплохая библиотека libevent, которая абстрагирует разные методы оповещения в общий интерфейс; я воспользовался ей при написании memcached, которым мы сейчас пользуемся в больших масштабах.