freebsd+nginx+php-fpm

[Gena Makhomed]

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

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, реализованная внутри frontend`а сервера.
неэффективная из-за постоянных повторных попыток подключения.

-- 
Best regards,
 Gena