LINUX.ORG.RU

История изменений

Исправление ei-grad, (текущая версия) :

1. Модуль socket не главная вещь из за которой можно так сказать, но многие вполне себе делают highload на питоне. Вообще - если поставить nginx перед питоном, то все пляски с backlog можно возложить на nginx. Но если очень хочется, то можно и питоном торчать наружу, не так уж всё и плохо.

2. Обычно reverse proxy (haproxy, nginx) позволяют определить backlog в конфиге.

3. Reverse proxy в первую очередь асинхронные, а использовать ли многопоточность или другие способы масштабирования по ядрам - зависит от ситуации.

Каким образом можно избежать reject'а от переполненной очереди, чтобы высокая нагрузка приводила только к разрыву по tcp connect timeout, но не icmp reject?

Выставить backlog в SOMAXCONN, например. Но так делать не надо, почему - ответ в самом вопросе.

Исправление ei-grad, :

1. Модуль socket не главная вещь из за которой можно так сказать, но многие вполне себе делают highload на питоне. Вообще - если поставить nginx перед питоном, то все пляски с backlog можно возложить на nginx. Но если очень хочется, то можно и питоном торчать наружу, не так уж всё и плохо.

2. Обычно reverse proxy (haproxy, nginx) позволяют определить backlog в конфиге.

3. Reverse proxy в первую очередь асинхронные, а использовать ли многопоточность или другие способы масштабирования по ядрам - зависит от ситуации.

Каким образом можно избежать reject'а от переполненной очереди, чтобы высокая нагрузка приводила только к разрыву по tcp connect timeout, но не icmp reject?

Выставить backlog в SOMAXCONN, например.

Исходная версия ei-grad, :

1. Модуль socket не главная вещь из за которой можно так сказать, но многие вполне себе делают highload на питоне. Вообще - если поставить nginx перед питоном, то все пляски с backlog можно возложить на nginx. Но если очень хочется, то можно и питоном торчать наружу, не так уж всё и плохо.

2. Обычно reverse proxy (haproxy, nginx) позволяют определить backlog в конфиге.

3. Reverse proxy в первую очередь асинхронные, а использовать ли многопоточность или другие способы масштабирования по ядрам - зависит от ситуации.

Каким образом можно избежать reject'а от переполненной очереди, чтобы высокая нагрузка приводила только к разрыву по tcp connect timeout, но не icmp reject?

Выставить backlog в 10000, например.