Спасибо за уточнение. Но всё же захват и освобождение GIL весьма непредсказуемые вещи. Не хочется лишний раз рисковать временем ответа. Плюс перед самой отправкой в Kafka у нас имеется весьма тяжёлый конвертер в protobuf, который не хотелось бы вызывать в процессе, обрабатывающем входящие запросыю
> Тоже интересно как решали, при 5000 RPS выглядит как потенциально большая проблема.
Воркеров суммарно немало. Процессов, пишущих в Kafka, тоже. Поэтому нагрузка на каждый отдельный процесс не такая большая.
Кроме того, что будет с пишущим процессом, если читающий умер? Он блокируется полностью?
Нет, пишущий процесс не блокируется. Он так же отдаёт ответ и пишет в очередь. Если что-то случится с читающим процессом, то мы его перезапускаем. Да, часть данных потеряется, но это не критично, т.к. на самих пользователях не скажется
Спасибо за уточнение. Но всё же захват и освобождение GIL весьма непредсказуемые вещи. Не хочется лишний раз рисковать временем ответа. Плюс перед самой отправкой в Kafka у нас имеется весьма тяжёлый конвертер в protobuf, который не хотелось бы вызывать в процессе, обрабатывающем входящие запросыю
Воркеров суммарно немало. Процессов, пишущих в Kafka, тоже. Поэтому нагрузка на каждый отдельный процесс не такая большая.
Нет, пишущий процесс не блокируется. Он так же отдаёт ответ и пишет в очередь. Если что-то случится с читающим процессом, то мы его перезапускаем. Да, часть данных потеряется, но это не критично, т.к. на самих пользователях не скажется
Сравним со входным объёмом данных. В среднем примерно 1-2 Кб
У нас настроен graceful shutdown. Когда ловим сигнал о завершении процесса, то сперва отправляем все неотправленные данные и только потом выключаемся.