Hello! On Thu, Mar 20, 2014 at 12:03:23PM +0000, Anatoly Mikhailov wrote:
On 19 Mar 2014, at 13:37, Maxim Dounin <mdounin@xxxxxxxxxx> wrote:
Hello!
On Wed, Mar 19, 2014 at 10:42:26AM +0000, Anatoly Mikhailov wrote:
On 18 Mar 2014, at 15:10, Maxim Dounin <mdounin@xxxxxxxxxx> wrote:
[...] супер, переписал конфигурацию для проксирования S3 на upstream, получилось очень классно,
вопрос - почему бы не сделать keepalive для бэкэнда по умолчанию?
Использование постоянных соединений полезно в основном в тех
случаях, когда до бекенда - далеко. В условиях близких бекендов
оно обычно не нужно. Наоборот, в некоторых ситуациях постоянные
соединения могут повредить - например, если бекенд сильно ограничен по
количеству соединений, которые он может обрабатывать. В
документации даже специально добавлено замечание про это, т.к.
люди периодически наступают, cм. http://nginx.org/r/keepalive/ru.
Так что я к идее сделать keepalive к бекендам поведением по
умолчанию - отношусь скептически.
Я правильно понимаю, keepalive (в контексте upstream) задает количество
TCP соединений, которые не будут закрываться, даже при отсутствии будущих запросов?
Да. Следует, однако, учитывать, что это число - на каждый рабочий процесс. Если да, то какой таймаут, такой же как для клиентских TCP подключений, указанных
через директиву keepalive_timeout?
Таймаут определяется тем, сколько соединение будет поддерживать бекенд. Сам nginx ничего закрывать не пытается. Вопрос второй - если известно, что бэкэнд держит, скажем, 50 соединений,
то keepalive 50 поможет нам повторно их использовать в будущем, без повторных syn+ack?
Если бекенд держит только 50 соединений, то ставить в конфиге "keepalive 50" - нецелесообразно, т.к. при таких настройках весь бекенд может быть занят одним рабочим процессом.
Все понятно, кроме этого момента. Если keepalive - нижняя граница, то второй рабочий процесс откроет больше соединений, чем указано в keepalive... или здесь все по другому?
|
