Нельзя делать сразу обработку, т.к. обработка зависит от других сеансов, т.е. это нужно запускать фоновое для обработки данных от всех сеансов сразу
Запуск фонового может занимать до +20мс, плюс запуск фонового на каждый запрос при учете возможного наличия уже работающего тоже печаль

Вариант с обработкой сразу уже пройден, там есть косяки честного распределения данных по запросам и часть запросов отваливается по тайм-ауту

И.е у вас задание обработки не параллелится и корректео работает только с полным набором данных x - записей. С отдельной записью не корректео работает?

Также есть вариант в качестве таймера использовать не регламентное задание на сервере (точность секунда) а роботов-таймеров запускаемых с клиента через метод подключить обработчикожидания (интервал 0.1 сек). Если еще быстрее нужно то генерить внешнее событие из таймера/компоненты на с++

Не понял, в чем твой вопрос и какие проблемы использовать регистрацию на узле плана обмена

Никаких проблем нет

Там задание не обработки, а фактически распределения сеансов по запросам. Запросы - это тоже отдельные потоки. Для честного распределения необходимо это делать в одном месте, т.к. иначе часть запросов не получают сеансы

Вопрос в общем не таймера, а скорее триггера для запуска обработки

Есть вероятность, что на самом деле даже с триггером плотность запросов будет такая, что оно все равно будет работать постоянно, но вряд ли так будет ночью

Вопрос сведения вносить сразу при записи документа или отложено, регистрируя только факт изменения данных при записи документа.

Давайте формализуем. У вас несколько потоков могут одновременно вносить новые данные в очередь. Очередь распределяется менеджером который может работать только однопоточно. Возникает проблема запуска этого менеджера, регл.задание (минимальный интервал 1 сек) фоновые (не гарантирую однопоточности. Т.е задача сводится к тому как запустить однопоточный менеджер чаще чем 1 раз в секунду?

Смотря насколько хочешь минимизировать увеличение длительности транзакции и снижение надежности кода.
Вариант с регистрацией на узле плана обмена кажется наименее рискованным по обоим критериям.

Я так и сначала и подумал.
Потом решил открыть книгу по интеграциям 1С. Открываю главу про планы обмена и читаю, что механизм состоит из трех частей, только одна из которых регистраци изменений. А обработку, доставку и удаление мне все равно делать самому. Да и в книге тонкой линий проходит, что мол не надо юзать план обмена если нет других узлов и саму в себя базу данных обменивать не надо.
Вот. Я тут и начал думать, что прикручю свой механизм регистрации простой, тем более что мне нужна последняя версия.

Задача в том, как запускать это одно фоновое только тогда, когда в регистре появляются данные, с минимальными накладными расходами на запуск

Потом уже вот начал делать сразу при записи документа, завтра посмотрю как получается, если все будет быстро и мне понравится, то оставлю так. Или сделаю отложено. Или часть подзадач так сделаю а часть по-другому. Заодно и попробую.

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

Да. Так наверное и буду делать.

Несколько способов попробую.

Я честно говоря читал в книге и ничего не понял. Завтра попробую почитать на ИТС и ИС. Услышал тебя. Еще разок попробую повнимательнее изучить этот механизм.

1. Таймер на механизме Регламентное задания (минимальный интервал мин из значений(1 сек или время работы задания) 2. Таймер на клиенте минимальный интервал 0.1 сек 3. Таймером управляет внешняя система (внешняя клмпонента, http сервис и т.п) минимальный интервал прлизвольный. 4. Нет таймера фоновыезадание.выполнить по окончании каждого цикла обмена плюс контрольное регламентное е ли фоновые с ошибкой упадут 5. Нет таймера синхронный вызов менеджера после каждого цикла обмена плюс контрольное регл.задание есди код упал с ошибкой. 6 переписать менеджер на многопоточную работу  какие еще варианты?