Comments 6
Данные, предназначенные для Kafka, мы стали записывать в multiprocessing.Queue,
А какой объём данных?
При мягкой перезагрузке сервера данные успевают отправится?
Если процесс убьют, то получается пользователь получит ответ, а данные в кавку не уйдут.
Тоже интересно как решали, при 5000 RPS выглядит как потенциально большая проблема. Кроме того, что будет с пишущим процессом, если читающий умер? Он блокируется полностью?
> Тоже интересно как решали, при 5000 RPS выглядит как потенциально большая проблема.
Воркеров суммарно немало. Процессов, пишущих в Kafka, тоже. Поэтому нагрузка на каждый отдельный процесс не такая большая.
Кроме того, что будет с пишущим процессом, если читающий умер? Он блокируется полностью?
Нет, пишущий процесс не блокируется. Он так же отдаёт ответ и пишет в очередь. Если что-то случится с читающим процессом, то мы его перезапускаем. Да, часть данных потеряется, но это не критично, т.к. на самих пользователях не скажется
А какой объём данных?
Сравним со входным объёмом данных. В среднем примерно 1-2 Кб
При мягкой перезагрузке сервера данные успевают отправится? Если процесс убьют, то получается пользователь получит ответ, а данные в кавку не уйдут.
У нас настроен graceful shutdown. Когда ловим сигнал о завершении процесса, то сперва отправляем все неотправленные данные и только потом выключаемся.
то это +5 мс ко времени ответа
Это не совсем так. Интервал переключения по умолчанию действительно 5 мс, но активный поток может отпустить GIL и раньше. Та же `kafka-python` использует epoll/kqueue, поэтому не будет долго держать GIL.
При этом верно и обратное, если CPU-bound задача долгая, то GIL может удерживаться дольше 5 мс, потому что эта проверка происходит перед выполнением очередной инструкции байт-кода. В kafka-python (да и в любой другой клиентской библиотеке) такой задачей будет только сериализация данных перед отправкой.
История оптимизации Python сервиса: пара простых системных улучшений