Comments 5
Вроде бы очевидная вещь, но кто-то всегда забывает, что обработка может занять больше времени, чем интервал опроса.
Обычно так: оно всегда идеально отрабатывает на компьютере разработчика, а в продакшне начинаются проблемы.
Я встречался с реальной утечкой памяти из-за send_interval, сделанного мною же по лени. Проблема была в том, что буйствующий процесс (он перебирал файлы на диске) отправлял всю остальную систему в даун из-за перегрузки.
Я встречался с реальной утечкой памяти из-за send_interval, сделанного мною же по лени. Проблема была в том, что буйствующий процесс (он перебирал файлы на диске) отправлял всю остальную систему в даун из-за перегрузки.
в эрланге специфичное сопряжение с аппаратным таймером — неизбежны запаздывания реализовать это проблематично, хотя повозиться стоит. Фактически, нельзя гарантировать точно срабатывание таймера — только рассчитывать на вероятностный доверительный интервал. Это палка о двух концах. Допустим есть сопряжение с таймером. Приходит «тик» от «железки» в эрланг, а он в этот момент загружен «тяжелой» операцией. Будем считать для простоты, что «тик» сразу стартует новый процесс, отвечающий за шедуллинг одного такта (буфера от железки нет, вместо буфера spawn процесса). Зажигаем красную лампочку. Кое-как процессу дается квант времени и он делает spawn… В этом месте неясно насколько быстр вызов spawn, если все висит (будем вынуждены считать, что железка не делает «тик», когда занята — горит красная лампочка). Процесс сопряженный с задачей «тика» отработал и готов к новым циклам. Загорается зеленая лампочка. Допустим задержка была 3 сек. Получаем 3-х секундный перерыв. Со светофором все просто. В общем простейшая схема.
Далее можно накручивать логику. Задействуем буфер виртуального или реального устройства. Если горит красная лампочка кладем в буфер и выставляем флаг, что надо обработать буфер. Процесс-обработчик тиков проверяет буфер когда будет доступен в очередном такте (мы не можем сразу обработать буфер — лампочка красная т.к. обработчик занят). Обрабатывает его и возвращаемся к нормальной схеме опять. Если лампочка зеленая, то соответственно сразу spawn.
С буфером картина примерно такая: Процесс-потребитель получит примерно одновременно 3-и вызова при синхронной обработке, соответственно получим либо тайм-аут (по умолчанию 5 сек) либо (у нас быстрый канал и проверка урла занимает 1 сек) 3-и последовательных запроса. Происходит как-бы эффект «проталкивания» тиков.
Ну соответственно процесс-потребитель может иметь логику не запускаться подряд а строго с соблюдением интервала или пропускать такие сообщения или вычислять необходимость их запуска или проталкивать с нормализацией интервалов (выравнивание интервалов)
Далее можно накручивать логику. Задействуем буфер виртуального или реального устройства. Если горит красная лампочка кладем в буфер и выставляем флаг, что надо обработать буфер. Процесс-обработчик тиков проверяет буфер когда будет доступен в очередном такте (мы не можем сразу обработать буфер — лампочка красная т.к. обработчик занят). Обрабатывает его и возвращаемся к нормальной схеме опять. Если лампочка зеленая, то соответственно сразу spawn.
С буфером картина примерно такая: Процесс-потребитель получит примерно одновременно 3-и вызова при синхронной обработке, соответственно получим либо тайм-аут (по умолчанию 5 сек) либо (у нас быстрый канал и проверка урла занимает 1 сек) 3-и последовательных запроса. Происходит как-бы эффект «проталкивания» тиков.
Ну соответственно процесс-потребитель может иметь логику не запускаться подряд а строго с соблюдением интервала или пропускать такие сообщения или вычислять необходимость их запуска или проталкивать с нормализацией интервалов (выравнивание интервалов)
Sign up to leave a comment.
Периодическая посылка сообщений