Re: freebsd+nginx+php-fpm

[Gena Makhomed <gmm@xxxxxxxxx>]

On Thursday, June 18, 2009 at 20:39:22, Andrei Nigmatulin wrote:

>> >> AN> Во-вторых, при переполнении listening queue
>> >> AN> в случае unix sockets клиент будет получать ошибку 502

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

AN> Тогда оставьте в покое listening queue. Отправлять запрос
AN> на резервный backend надо через fastcgi_connect_timeout.

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

в предлагаемом Вами варианте - frontend тупо ждет 60 секунд,
и только через 60 сек он начинает соображать, что этот backend
уже будет не в состоянии обработать этот конкретный новый запрос.

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

AN> Иначе непонятен смысл - вы не беспокоитесь за судьбу
AN> уже зависших в listening queue соединений,

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

AN> но беспокоитесь за те, которые его переполнят.

когда listening queue у работающего backend`а
уже переполнена - новые запросы этим backend`oм
обрабатывались бы слишком долго - клиенты столько
времени ждать ответа не станут. поэтому - сразу 502.

и у frontend`а появляется шанс решить эту проблему.

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

>> фактически это будет еще одна, достаточно неэффективная,
>> listening queue, реализованная внутри frontend`а сервера.
>> неэффективная из-за постоянных повторных попыток подключения.

AN> Ну поскольку вы предлагаете в качестве альтернативы
AN> все избыточные запросы отправлять на второй backend

я прежде всего предлагаю не изобретать велосипед с квадратными колесами, -
я предлагаю использовать backlog по его прямому назначению, для сглаживания
"всплесков (кратковременному, непериодическому увеличению) кол-ва запросов".

см. также исходное сообщение треда http://www.lexa.ru/nginx-ru/msg25660.html

также как и "Retransmission of lost packets" из TCP протокола
я предлагаю использовать по его прямому назначению для повторной
пересылки потерявшихся в пути пакетов. и только лишь для этого.

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

не понял вопрос.

может быть сначала полностью рассмотрим вариант
когда есть только один backend и только один frontend ?

-- 
Best regards,
 Gena