freebsd+nginx+php-fpm

Fri Jun 19 00:16:44 MSD 2009

On Thursday 18 June 2009 23:13, Gena Makhomed wrote:
> AN> Тогда оставьте в покое listening queue. Отправлять запрос
> AN> на резервный backend надо через fastcgi_connect_timeout.
>
> в случае переполнения listening queue, т.е. когда backend понимает,
> что он уже не в состоянии обработать новые запросы - frontend
> практически мгновенно получает 502 ошибку от этого backend`а.
>
> в предлагаемом Вами варианте - frontend тупо ждет 60 секунд,
> и только через 60 сек он начинает соображать, что этот backend
> уже будет не в состоянии обработать этот конкретный новый запрос.
>
> честно, - не понимаю, чем предлагаемый Вами вариант лучше.
> обычно время, которое затрачивается на обработку запросов
> клиентов стараются уменьшать, а не искуственно увеличивать.

Я подразумеваю, что у нас имеется обычный web сайт, один фронтенд и несколько 
backends. Я подразумеваю, что все backends равномерно загружены запросами и 
резервных нет. Ну вот не вижу смысла держать резервные простаивающие 
backends, правда.

В случае всплесков мне нужно пытаться обслужить клиента до последнего и мне 
бесполезна возможность моментально узнать что backend загружен под завязку. 
Скорее всего, это значит, что остальные backends в похожем состоянии, и 
запросу все равно суждено висеть пока не он обработается или клиент не 
устанет ждать. Это все что я могу сделать. Как мне тут может помочь 502 
ошибка ?

> AN> Иначе непонятен смысл - вы не беспокоитесь за судьбу
> AN> уже зависших в listening queue соединений,
>
> они не зависли, они стоят в очереди на обработку.
> backend работает, но он уже перегружен запросами.
> и те запросы, что стоят в очереди он обработает
> за допустимый период времени. тут все нормально.
>
> AN> но беспокоитесь за те, которые его переполнят.
>
> когда listening queue у работающего backend`а
> уже переполнена - новые запросы этим backend`oм
> обрабатывались бы слишком долго - клиенты столько
> времени ждать ответа не станут. поэтому - сразу 502.
>
> и у frontend`а появляется шанс решить эту проблему.

Как мне на практике использовать этот шанс ? Как для вышеописанной ситуации 
мне может помочь 502 ошибка ?

> >> AN> А вы видели хоть одного администратора, который знает как правильно
> >> AN> расчитать размер listening queue, исключая подбор значений
> >> экмпериментально ?
> >>
> >> разве это так сложно? len( listening queue ) == wait_time /
> >> response_time wait_time - сколько времени средний клиент захочет ждать
> >> ответ от сервера response_time - среднее время обработки одного запроса
> >> backend`ом сервера
> >>
> >> например, в случае wait_time == 20 sec, response_time == 0.020 sec
> >> размер listening queue для этого backend`а будет равен 1024.
> >> для гарантии можно этот параметр увеличить в полтора-два раза.
> >>
> >> но при len( listening queue ) == 10000, response_time == 0.020 sec
> >> и при заполнении listening queue - запросы будут проводить в ней
> >> по 200 секунд. и *каждый* клиент будет ~ 200 секунд ждать ответ.
>
> AN> И где тут учитываются всплески ?
>
> в размере listening queue. исходя из параметров производительности
> backend`а (сколько времени он тратит в среднем на обработку запроса)
> и исходя из QoS показателя, сколько времени сервер может заниматься
> обработкой одного клиентского запроса.
>
> AN> Обслуживать поток запросов с постоянной плотностью просто и скучно.
> AN> Да и на практике такое редко встретишь.
>
> плотность переменная. в результате размер listening queue
> также становится переменным от 0 до len( listening queue ).
>
> время обработки запросов клиентов - также изменяется от 0
> до wait_time. если backend понимает, что новый запрос он
> скорее всего не успеет обработать за wait_time секунд -
> тогда он сразу же возвращает frontend`у 502-ю ошибку.
>
> когда новые запросы поступают быстрее, чем backend успевает
> их обрабатывать - тогда они становятся в listening queue,
> и количество запросов в listening queue увеличивается.
> (это - работа во время всплеска)
>
> когда backend обрабатывает запросы быстрее,
> чем появляются новые - тогда количество запросов
> в listening queue постепенно уменьшается.
> (это - работа после всплеска)
>
> >> >> AN> тогда как tcp поддерживает retransmission и соответственно,
> >> >> AN> более устойчив к всплескам (кратковременному, непериодическому
> >> >> AN> увеличению) кол-ва запросов.
> >> >>
> >> >> feature "Retransmission of lost packets" работает
> >> >> уже после того, как было установлено соединение.
> >>
> >> AN> По крайней мере в случае linux сервера это не так.
> >> AN> Клиентский syn просто игнорируется, если listening queue полный.
> >>
> >> $subj. а в случае linux это будет "wasting of resources" сервера,
> >> потому что вместо ответа "да" или "нет" frontend будет получать
> >> от backend`а нечеткий ответ "может быть", и будет повторять попытки.
>
> AN> Значит, listening queue на бекенде можно тюнить,
> AN> а кол-во соединений в nginx нельзя ?
>
> все можно. но эффективнее использовать
> встроенную в ядро фичу - listening queue.
>
> если запрос попал в backlog(*) - скорее всего он будет обработан.
> если не попал - точно не будет и frontend сразу получит 502 ответ.
>
> (*) socket backlog и socket listening queue - это одно и то же.
>
> AN> Посчитайте по формулам и установите сколько надо,
> AN> не будет никакого resource wasting.
>
> будет в предлагаемом Вами варианте - вместо тюнинга backlog`а
> надеяться на retransmission из Transmission Control Protocol.

Я не говорю что backlog выставлять не нужно. Я говорю, что сколько вы не 
выставляйте, все равно есть ненулевая вероятность, что в единицу времени 
может прийти запросов больше, чем расчитывалось при выставлении backlog. Это 
теория массового обслуживания, ничего личного.

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

А я предлагаю делать безглючные сайты, когда я не знаю что делать с 502 
ошибкой на фронтенде. Если человек видит внизу броузера "Waiting for 
reply...", а не рефрешит страницу error_page 502, где красиво написано о том 
что сервер недоступен, то общее количество поступающих запросов громадным 
образом снижается, и авария постепенно сходит на нет. Так показывает опыт. По 
мне, клиент, долбящий frontend гораздо страшнее, чем frontend, ожидающий 
медленный backend. Это - экономия ресурсов, а не wasting.

> см. также исходное сообщение треда
> http://www.lexa.ru/nginx-ru/msg25660.html
>
> также как и "Retransmission of lost packets" из TCP протокола
> я предлагаю использовать по его прямому назначению для повторной
> пересылки потерявшихся в пути пакетов. и только лишь для этого.

Предлагайте. Вполне допускаю, что ваш подход тоже может быть полезен для 
определенных задач.

> AN> то непонятно, чем пассивная очередь ожидающих установления
> AN> соединений может быть хуже чем такое же количество активных
> AN> соединений до второго backend.
>
> не понял вопрос.
>
> может быть сначала полностью рассмотрим вариант
> когда есть только один backend и только один frontend ?

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