Re: freebsd+nginx+php-fpm

[Andrei Nigmatulin <andrei.nigmatulin@xxxxxxxxx>]

On Thursday 18 June 2009 20:29, Gena Makhomed wrote:
> On Thursday, June 18, 2009 at 17:43:14, Andrei Nigmatulin wrote:
> >> overhead в случае unix sockets меньше,
> >> поэтому они должны быть быстрее чем tcp.
>
> AN> Мне тоже интуитивно кажется, что они должны быть быстрее. Хочется
> увидеть AN> конкретные цифры. Правильный бенчмарк, который все расставит по
> местам.
>
> конкретные цифры можно увидеть с помощью бенчмарка http://www.netperf.org/
>
> >> AN> Во-вторых, при переполнении listening queue
> >> AN> в случае unix sockets клиент будет получать ошибку 502
> >>
> >> listening queue как раз и предназначена для сглаживания всплесков.
> >> 502 ошибку будут получать только те клиенты, которых backend сервера
> >> уже гарантированно не успеет обслужить, поэтому сразу возвращает ошибку.
> >>
> >> администратору всего лишь следует
> >> адекватно настроить размер listening queue.
>
> AN> Все дело в силе всплесков и плотности потока запросов.
> AN> Можно и 10000 поставить и этого не хватит в момент затупления базы.
>
> в момент "затупления базы" и переполнения listening queue -
> backend фактически не работоспособен. лучше честно вернуть
> 502 ошибку, чем пытаться имитировать какую-то деятельность.

Это для вашей конкретной ситуации может быть лучше. Не вижу чем это лучше для 
меня, например.

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

Тогда оставьте в покое listening queue. Отправлять запрос на резервный backend 
надо через fastcgi_connect_timeout. Иначе непонятен смысл - вы не 
беспокоитесь за судьбу уже зависших в listening queue соединений, но 
беспокоитесь за те, которые его переполнят.

> AN> Я исхожу из практических соображений и опыта.
>
> я исхожу из теоретических соображений и опыта.
>
> 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> тогда как tcp поддерживает retransmission и соответственно,
> >> AN> более устойчив к всплескам (кратковременному, непериодическому
> >> AN> увеличению) кол-ва запросов.
> >>
> >> feature "Retransmission of lost packets" работает
> >> уже после того, как было установлено соединение.
>
> AN> По крайней мере в случае linux сервера это не так.
> AN> Клиентский syn просто игнорируется, если listening queue полный.
>
> $subj. а в случае linux это будет "wasting of resources" сервера,
> потому что вместо ответа "да" или "нет" frontend будет получать
> от backend`а нечеткий ответ "может быть", и будет повторять попытки.

Значит, listening queue на бекенде можно тюнить, а кол-во соединений в nginx 
нельзя ? Посчитайте по формулам и установите сколько надо, не будет никакого 
resource wasting.

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

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


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