Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: freebsd+nginx+php-fpm
On Thursday, June 18, 2009 at 23:16:44, Andrei Nigmatulin wrote:
>> AN> Тогда оставьте в покое listening queue. Отправлять запрос
>> AN> на резервный backend надо через fastcgi_connect_timeout.
вот этой Вашей рекомендации я не понимаю. вместо тюнинга размера
listening queue вы предлагаете полагаться на tcp retransmissions
и ждать пока frontend устанет долбить перегруженный backend новыми запросами,
что будет только мешать этому backend`у нормально обрабатывать старые запросы.
fastcgi_connect_timeout - это ~ 60 секунд, и вряд-ли клиент дождется
даже первого перехода между backend`ами, не говоря уже об остальных.
переходы между backend`ами по 502-й ошибке будут происходить практически
мгновенно и здесь действительно появляется шанс обработать запрос клиента
на каком-то менее загруженном или резервном backend`е, если изначально
запрос клиента попал на перегруженный обработкой запросов backend.
>> в случае переполнения listening queue, т.е. когда backend понимает,
>> что он уже не в состоянии обработать новые запросы - frontend
>> практически мгновенно получает 502 ошибку от этого backend`а.
>> в предлагаемом Вами варианте - frontend тупо ждет 60 секунд,
>> и только через 60 сек он начинает соображать, что этот backend
>> уже будет не в состоянии обработать этот конкретный новый запрос.
>> честно, - не понимаю, чем предлагаемый Вами вариант лучше.
>> обычно время, которое затрачивается на обработку запросов
>> клиентов стараются уменьшать, а не искуственно увеличивать.
AN> Я подразумеваю, что у нас имеется обычный web сайт, один фронтенд
AN> и несколько backends. Я подразумеваю, что все backends равномерно
AN> загружены запросами и резервных нет. Ну вот не вижу смысла держать
AN> резервные простаивающие backends, правда.
резервные (backup) backend`ы могут быть полезны для сглаживания особенно
больших всплесков, с которыми активные backend`ы уже не могут справиться.
когда всплесков нет - они могут выполнять другие, менее приоритетные задачи.
один из возможных вариантов обработки 502 ошибки - это proxy_cache_use_stale,
рано или поздно аналогичная функциональность появится и в
ngx_http_fastcgi_module.
AN> В случае всплесков мне нужно пытаться обслужить клиента до последнего и мне
AN> бесполезна возможность моментально узнать что backend загружен под завязку.
Вы видели хотя бы одного клиента который будет сидеть перед монитором и ждать
ответ от сервера например, 60 секунд ? обычное больше 5-15 секунд не ждут.
AN> Скорее всего, это значит, что остальные backends в похожем состоянии,
AN> и запросу все равно суждено висеть пока не он обработается или клиент
AN> не устанет ждать. Это все что я могу сделать.
AN> Как мне тут может помочь 502 ошибка ?
502 ошибка может помочь увидеть, что существующие backend`ы
уже не справляются с возрозшей нагрузкой из нормальных клиентов,
и нужно увеличивать их скорость обработки запросов, или же - что сайт
находится под DDoS-атакой и надо лучше фильтровать ботов от пользователей.
есть два подхода - "make it good" и "make it looks good".
например, когда в Python возникает какая-то исключительная ситуация,
он не пытается делать вид, что все хорошо, а выбрасывает exception.
>> когда listening queue у работающего backend`а
>> уже переполнена - новые запросы этим backend`oм
>> обрабатывались бы слишком долго - клиенты столько
>> времени ждать ответа не станут. поэтому - сразу 502.
>> и у frontend`а появляется шанс решить эту проблему.
AN> Как мне на практике использовать этот шанс ?
AN> Как для вышеописанной ситуации мне может помочь 502 ошибка ?
например, добавить backup`ных backend`ов для обработки всплесков.
если действительно, "в случае всплесков нужно обслужить клиента".
...
>> AN> не будет никакого resource wasting.
>> будет в предлагаемом Вами варианте - вместо тюнинга backlog`а
>> надеяться на retransmission из Transmission Control Protocol.
AN> Я не говорю что backlog выставлять не нужно.
"Тогда оставьте в покое listening queue" - это Ваши слова?
AN> Я говорю, что сколько вы не выставляйте, все равно есть ненулевая
AN> вероятность, что в единицу времени может прийти запросов больше,
AN> чем расчитывалось при выставлении backlog.
если размер backlog`а backend`а выставлен адекватно - это означает
что поток запросов больше чем мощность этого backend`а, и эту ситуацию
уже нельзя будет назвать словом "кратковременный всплеск", потому *все*
кратковременные всплески *сглаживаются* с помощью backlog`а backend`а.
>> >> фактически это будет еще одна, достаточно неэффективная,
>> >> listening queue, реализованная внутри frontend`а сервера.
>> >> неэффективная из-за постоянных повторных попыток подключения.
>> AN> Ну поскольку вы предлагаете в качестве альтернативы
>> AN> все избыточные запросы отправлять на второй backend
>> я прежде всего предлагаю не изобретать велосипед с квадратными колесами, -
>> я предлагаю использовать backlog по его прямому назначению, для сглаживания
>> "всплесков (кратковременному, непериодическому увеличению) кол-ва запросов".
AN> А я предлагаю делать безглючные сайты,
подход "make it looks good" или все-таки "make it good" ?
AN> когда я не знаю что делать с 502 ошибкой на фронтенде.
можно придумать что-то интереснее чем полное зависание и ноль реакции.
AN> Если человек видит внизу броузера "Waiting for reply...",
AN> а не рефрешит страницу error_page 502, где красиво написано о том
AN> что сервер недоступен, то общее количество поступающих запросов громадным
AN> образом снижается, и авария постепенно сходит на нет. Так показывает опыт.
так "авария" или "всплеск" ? мы тут вроде бы обсуждали обработку
кратковременных и непериодических всплесков количества запросов.
сглаживанием *всплесков* занимается именно backlog, если его размер
настроен администратором адекватно двум ранее названным параметрам.
насколько я понимаю, frontend`ы проще масштабировать чем backend`ы,
потому что они могут выдержать гораздо большее количество запросов,
да и выдача статики, которая уже лежит в кеше должна быть практически
мгновенной, по сравнению с обработкой тяжелых запросов backend`ами.
по крайней мере, Google не стесняется признаваться пользователям,
что у них проблемы с backend`ами, несколько раз видел на Gmail
их сообщение о 502-й ошибке. и почему-то у меня совсем не было
желания в тот момент сидеть и постоянно рефрешить эту страницу.
тем более, что рефреш страницы www.example.com/502.html
всегда будет возвращать только эту статическую страницу
AN> По мне, клиент, долбящий frontend гораздо страшнее, чем frontend,
AN> ожидающий медленный backend. Это - экономия ресурсов, а не wasting.
и Вы предлагаете сделать frontend долбящий громадным количеством
запросов и так уже перегруженные обработкой запросов backend`ы ?
если у вас что-то постоянно рефрешит страницы - это боты,
а не пользователи. и такая ситуация называется "DDoS-атака",
это совсем не "кратковременный всплеск нормальных запросов".
причина проблемы тогда в том, что не совсем качественно
отфильтровываются DDoS-боты от нормальных пользователей,
и тюнить размер listening queue в этом случае нет смысла,
как и долбить frontend`ом и так уже перегруженные backend`ы.
доводить сервер до состояния, когда все пользователи видят
пустой екран и сообщение браузера "Waiting for reply..."
в статусной строке - это трудно назвать словом "solution".
поможет наверное только Cisco Guard DDoS Mitigation Appliances
или аналогичные програмно-аппаратные решения для защиты от DDoS.
======================================================================
On Thursday, June 18, 2009 at 15:41:37, Andrei Nigmatulin wrote:
AN> при переполнении listening queue в случае unix sockets
AN> клиент будет получать ошибку 502, тогда как tcp поддерживает
AN> retransmission и соответственно, более устойчив к всплескам
AN> (кратковременному, непериодическому увеличению) кол-ва запросов.
======================================================================
скорее всего под словосочетанием "кратковременный всплеск" Вы здесь
подразумеваете фразу "DDoS-атака" или "авария на части backend`ов".
--
Best regards,
Gena
|