freebsd+nginx+php-fpm

[Andrei Nigmatulin]

On Friday 19 June 2009 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`у нормально обрабатывать
> старые запросы.

Ерунда. backend как обрабатывал запросы так и будет обрабатывать. Будут его 
долбить tcp retransmission или пользователи, загружающие error_page 502 и 
нажимающие refresh - на скорость исполнения запросов НЕ ПОВЛИЯЕТ.

> fastcgi_connect_timeout - это ~ 60 секунд, и вряд-ли клиент дождется
> даже первого перехода между backend`ами, не говоря уже об остальных.

Откуда эта магическая константа ? У меня в конфиге совсем другая.

> переходы между backend`ами по 502-й ошибке будут происходить практически
> мгновенно и здесь действительно появляется шанс обработать запрос клиента
> на каком-то менее загруженном или резервном backend`е, если изначально
> запрос клиента попал на перегруженный обработкой запросов backend.

Это он у вас есть, резервный backend или это навязчивая фантазия что он у всех 
должен быть ? Я повторяю, я не вижу особо смысла разделять backend'ы на 
основные и резервные и включать последние в бой только когда на первых 
появляются ошибки. Укажите мне, пожалуйста, в каких случаях может быть 
целесообразен простаивающий backend ? Очевидно, что чем больше backends 
обрабатывают запросы, тем меньше приходится на каждый из них, тем быстрее они 
обрабатываются, тем щасливее пользователи.

> >> в случае переполнения listening queue, т.е. когда backend понимает,
> >> что он уже не в состоянии обработать новые запросы - frontend
> >> практически мгновенно получает 502 ошибку от этого backend`а.
> >>
> >> в предлагаемом Вами варианте - frontend тупо ждет 60 секунд,
> >> и только через 60 сек он начинает соображать, что этот backend
> >> уже будет не в состоянии обработать этот конкретный новый запрос.
> >>
> >> честно, - не понимаю, чем предлагаемый Вами вариант лучше.
> >> обычно время, которое затрачивается на обработку запросов
> >> клиентов стараются уменьшать, а не искуственно увеличивать.
>
> AN> Я подразумеваю, что у нас имеется обычный web сайт, один фронтенд
> AN> и несколько backends. Я подразумеваю, что все backends равномерно
> AN> загружены запросами и резервных нет. Ну вот не вижу смысла держать
> AN> резервные простаивающие backends, правда.
>
> резервные (backup) backend`ы могут быть полезны для сглаживания особенно
> больших всплесков, с которыми активные backend`ы уже не могут справиться.
>
> когда всплесков нет - они могут выполнять другие, менее приоритетные
> задачи.

У вас так ? И в момент всплесков эти "менее приоритетные задачи" с резервного 
backend сразу перекидываются на еще один резервный backend, надо понимать ?

> один из возможных вариантов обработки 502 ошибки - это
> proxy_cache_use_stale, рано или поздно аналогичная функциональность
> появится и в ngx_http_fastcgi_module.

Это из разряда "если бы у рыбы была шерсть, то в ней водились бы блохи".

> AN> В случае всплесков мне нужно пытаться обслужить клиента до последнего и
> мне AN> бесполезна возможность моментально узнать что backend загружен под
> завязку.
>
> Вы видели хотя бы одного клиента который будет сидеть перед монитором и
> ждать ответ от сервера например, 60 секунд ? обычное больше 5-15 секунд не
> ждут.

5-15 отличное время, чтобы посидеть помедитировать на строчку "Waiting for 
reply...". Так будет делать средний пользователь, если ему не показывать 
error_page 502. Если показывать - будут часто рефрешить. Что вы выигрываете, 
если backend не отвечает, а запросов на фронтенд стало в несколько раз больше 
из-за этих refresh ?

> AN> Скорее всего, это значит, что остальные backends в похожем состоянии,
> AN> и  запросу все равно суждено висеть пока не он обработается или клиент
> AN> не устанет ждать. Это все что я могу сделать.
> AN> Как мне тут может помочь 502 ошибка ?
>
> 502 ошибка может помочь увидеть, что существующие backend`ы
> уже не справляются с возрозшей нагрузкой из нормальных клиентов,
> и нужно увеличивать их скорость обработки запросов, или же - что сайт
> находится под DDoS-атакой и надо лучше фильтровать ботов от пользователей.

Спасибо, я это и так могу посмотреть, например с помощью pinba. И даже выявить 
что именно тормозит: конкретный backend, конкретный скрипт или даже 
конкретный тип запросов на сервера бд. И насколько сильно тормозит, и когда 
началось могу увидеть, поскольку вся инфа с pinba про каждый backend попадает 
в rrd.

И мне не нужна для этого 502 ошибка.

> есть два подхода - "make it good" и "make it looks good".
>
> например, когда в Python возникает какая-то исключительная ситуация,
> он не пытается делать вид, что все хорошо, а выбрасывает exception.

Exception для программистов, а сайт для тупых пользователей. Чем меньше им 
показывать ошибок тем лучше. В этом разница здесь.

Я прошу прощения, но отвечать в рассылку вам больше не буду - устал. Мне 
кажется, что свою точку я изложил более чем развернуто, и если это 
кому-нибудь пригодится, то задача спора выполнена.


-- 
Andrei Nigmatulin
GPG PUB KEY 6449830D

Now I lay me down to sleep(3)
Pray the OS my core to keep
If I die before I wake
Pray the Disk my core to take