Re: freebsd+nginx+php-fpm

["Alexey V. Karagodov" <kav@xxxxxxxxxxxxxx>]

 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