История изменений
Исправление 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, например.