freebsd+nginx+php-fpm

[Gena Makhomed]

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