Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: freebsd+nginx+php-fpm
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
|