Коллеги, подскажите такой вопрос:
Есть у меня необходимость постоянно мониторить наличие каких-то данных в регистре, и если они есть, то запускать их обработку. Время реакции на их появление должно быть минимальным, при этом вешать запуск этой реакции на запись в регистр максимально не хочется, т.к. занимает время.
Частота появления данных - чаще секунды.
Пока пришел к идее постоянно висящего ФЗ, которое мониторит этот регистр в цикле, оно получается вполне неплохо, за исключением того, что это ФЗ фактически впустую жрет полностью один поток процессора.
Проблема еще в том, что потенциально таких фоновых может быть 5 и более.
И одной фоновое еще на логирование, но его предположим можно повесить на регламент раз в секунду, но где-то читал, что так тоже нельзя.
Может есть какие-то бест практис в этом всём?

Это всё равно фактически при записи набора и будет исполняться в потоке с записью данных, чего и нужно избежать

866?

Бест практис - не сношать мозг и для начала обосновать, почему "Время реакции на их появление должно быть минимальным" (меньше минуты).
Если не можешь обосновать, то и вопрос снимается.

это фоновое - распределитель сеансов между запросами
а запросы идут от пользователя, для которого время ответа больше секунды - это повод свалить и не оставить заказ

Секунда, это точно про 1с?

это фоновое - распределитель сеансов между запросами
а запросы идут от пользователя, для которого время ответа больше секунды - это повод свалить и не оставить заказ

Насколько эффективно "городить" вот такие вложенные соединения таблиц? (просто пример).
|ИЗ
|    РегистрСведений.ИзмененияСтатусаНоменклатуры.СрезПоследних(&Период, ) КАК ИзмененияСтатусаНоменклатуры
|        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК СпрНоменклатура
|            ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ТипыНоменклатуры КАК ТипыНоменклатуры
|            ПО СпрНоменклатура.ОписаниеНоменклатуры = ТипыНоменклатуры.Ссылка
|        ПО ИзмененияСтатусаНоменклатуры.Номенклатура = СпрНоменклатура.Ссылка
Пишут, что в данном случае соединение таблиц произойдет в таком порядке, в котором решит планировщик СУБД, результат от этого не зависит. А порядок соединений планировщик определяет в зависимости от объема вычислений при соединении данных на основе статистики, наличия индексов и других вспомогательных данных.
Действительно так?

Коллеги, подскажите такой вопрос:
Есть у меня необходимость постоянно мониторить наличие каких-то данных в регистре, и если они есть, то запускать их обработку. Время реакции на их появление должно быть минимальным, при этом вешать запуск этой реакции на запись в регистр максимально не хочется, т.к. занимает время.
Частота появления данных - чаще секунды.
Пока пришел к идее постоянно висящего ФЗ, которое мониторит этот регистр в цикле, оно получается вполне неплохо, за исключением того, что это ФЗ фактически впустую жрет полностью один поток процессора.
Проблема еще в том, что потенциально таких фоновых может быть 5 и более.
И одной фоновое еще на логирование, но его предположим можно повесить на регламент раз в секунду, но где-то читал, что так тоже нельзя.
Может есть какие-то бест практис в этом всём?

Коллеги, подскажите такой вопрос:
Есть у меня необходимость постоянно мониторить наличие каких-то данных в регистре, и если они есть, то запускать их обработку. Время реакции на их появление должно быть минимальным, при этом вешать запуск этой реакции на запись в регистр максимально не хочется, т.к. занимает время.
Частота появления данных - чаще секунды.
Пока пришел к идее постоянно висящего ФЗ, которое мониторит этот регистр в цикле, оно получается вполне неплохо, за исключением того, что это ФЗ фактически впустую жрет полностью один поток процессора.
Проблема еще в том, что потенциально таких фоновых может быть 5 и более.
И одной фоновое еще на логирование, но его предположим можно повесить на регламент раз в секунду, но где-то читал, что так тоже нельзя.
Может есть какие-то бест практис в этом всём?

Почему не веришь?

У меня есть регистр. Туда пишутся какие-то строки, мне нужно реагировать на появление флага в записи. Как только я его вижу, я запись копирую их в другой регистр. Фоновое задание запускается с любой периодичностью и смотрит в этот второй регистр и отправляет данные по почте. Если данных для отправки нет, то и ФЗ завершится, отпустив поток. Можно запускать этот ФЗ зоть каждые 10 секунд.

очень неэффективно. можно словить соединение с подзапросом

косячит, тяжелый и блокирует все и вся

Если время обработки существенное и нагрузка рваная  и нет проблем с лицензиями то обработку можео стартовать при записи в асинхроном режиме новое оновое задание

С точки зрения регистрации изменений ничем не отличается от того же регистра и даже легче, т.к. нет индексов. Тяжелее разве что из-за подхода "одна запись на один объект", а с регистром можно сделать неблокирующий инсерт (но с 8.3.16+ там вообще разницы нет - вычитываться содержимое будет один фиг даже перед вставкой без замещения и в режиме загрузки, как и в случае с планом обмена вычитывается запись с номером сообщения перед ее занулением при регистрации).
Но в обсуждаемом случае один и тот же документ все равно не будет параллельно пытаться регистрироваться, т.к. конкурирующие писатели объекта все равно встанут в очередь, а значит и момент регистрации выстроится в очередь.
А что за глюки?

А при чем тут лицензии? ФЗ их не потребляют. Хоть тыщу запускай.