freebsd+nginx+php-fpm

[Alexey V. Karagodov]

  fastcgi_connect_timeout 1s;
1с и то много
чего там от бекенда ждать дольше  
секунды?

  fastcgi_read_timeout 5s;
  fastcgi_send_timeout 5s;

и нет проблем
отдал страницу с извенениями, либо  
флеш туда, либо ещё что, что само  
отрефрешит или что то сделает красивое

а если что-то рефрешит страницу, то это  
нетерпеливый юзер
у меня есть сведения (не я их получал,  
но на практике подобное  
подтвердилось), что в среднем, тело  
ждёт 7 секунд и потом начинает  
нервничать
нажимать рефреш, закрывать страницу и  
тд и тп

Cisco Guard DDoS Mitigation Appliances не поможет от  
нормальных, начавших нервничать юзеров



On 19.06.2009, at 15:13, Gena Makhomed wrote:

> 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
>
>