По идеологии прикладной задачи предполагается вызов регламентного задания с частотой от 5 секунд.
Т.е. чаще чем какждые 5 секунд вызываться не планируется, но реже может.

Вопрос, к знающим, насколько это плохо? К каким последствиям (нежелательным) это может привести (краш сервера, переполнение памяти, общее замедление работы, переполнение лога и т.п.)
И если нежелательные последствия неизбежны - то какие пути их ликвидации. (ну кроме увеличения интервала разумеется)

Признателен за Ваши советы (адекватные разумеется)

(0) смотря что ты там в эти 5 секунд делаешь.

(0) Если будет вызывать 6 сек. ТО все сдохнет к чертям собачим

ВыбратьИзменения блокирует всю таблицу регистрации по узлу

а для остального без разницы

(1) (2) Собираюсь выполнить запрос, к регистру сведений, получить результат, упаковать в XML файл, и отправить на веб-сервер.
Предположительно должен уложиться в 5 секунд. Одно смущает... могу не успеть дождаться пока сервер вернет ответ.

А если поставить параметр "Завершать через" - равным 4 секундам. Это поможет. даже не смотря на то что сервер может не ответить?

может быть пусть лучше веб-сервер по необходимости запрашивает данные у веб-сервиса 1с?

И еще вариант, могу ли я запустить 4 одинаковых Регламетных задания с интервалом запуска 20 секунд и сдвигом по времени старта 5 секунд относительно старта предыдущего.
Решит ли это проблему, или это "те же яйца - только в профиль"?

(6) Необходимость формирует 1С... а не веб-сервер. Веб сервер тоже пихает в 1С информацию - если что-то происходит у него. (назовем это - действием пользователя)

А регистр как часто обновляется ?

(9) Регистр будет обновляется при каждом проведении документа содержащего Номенклатуру и Склад. Но при условии что после проведения остаток изменился.
Говоря простым языком при каждом списании оприходовании товара - регистр будет обновляться.

Что там за регистр такой сведений?
Я обычно складывал в свою таблицу SQL. А сторонняя приблуда-робот-1С мониторила ее содержимое (с признаком обработки или с удалением). Я думаю что не восьмерке, да еще и с коннектом к серверу не взлетит каждые 5 секунд.

Может замутить ср-вами SQL?

Фоновое задание может иметь ключ – любое прикладное значение. Ключ вводит ограничение на запуск фоновых заданий – в единицу времени может выполняться только одно фоновое задание с определенным значением ключа и заданным именем метода фонового задания (имя метода состоит из имени модуля и имени процедуры или функции). Ключ позволяет группировать фоновые задания, имеющие одинаковые методы, по определенному прикладному признаку с тем, чтобы в рамках одной группы выполнялось не более одного фонового задания.

(10) Просто, есть мнение, что задание должно запускаться в момент проведения документа, то есть тогда, когда в регистр записали. При записи сбрасывать флаг обновления, чтобы видеть, что никто в момент исполнения ничего не записал, а потом при завершении его проверять - если больше записи нет, то не стоит каждые пять секунд "дёргать" базу.

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

(10) ИМХО 5 сек опасно для таких вещей.
Если в регистр будет идти запись, то лучше не рисковать.

Я бы поменял логику действий.
Если уж совсем все плохо, то придумай, например константу (есть такой термин PID) .
Перед началом операции проверяй PID = 0, если да, то ПИШУ в него 1 и запускай процесс. Когда все сделал пиши туда опять 0.
Если вдруг запустится 2ой задание и увидит там 1 в PID. То просто выключиться

(12) Вот как раз неохота прикручивать что-либо стороннее. Крайне неохота. Ровно как и писать напрямую в базу данных сайта (как бы тут не кричали что это во сто крат быстрее любых других методов)

(14) Лучше уж дергать... прочитать табличку небольшую общую быстрее (в целом), чем что-то выполнять при проведениии.

(0) Объясни, плиз, зачем 5 сек? Почему нельзя 10?

(17) У меня был робот-1с. Он постоянно висел, т.е. ничего не стартовало. Напрямую тоже писал в MySQL, конечно быстрее.

(18) При проведении мы кидаем флаг, что нужно "дёрнуть" и выставляем команду исполнения регламента. Регламент потом запускается и "дёргает".
Если никто не провёлся, то запуск регламента проверяет флаг, меняет интервал своего исполнения на какое-то большое значение (или просто выключает регламент) и завершается.

Это интернет-магазин, что ли?

(14) Проведение документов (в теории) может происходить чеще чем 1 раз в 5 секунд.
На веб сайте поставили ограничение (логическое - на всякий) - не пихать в него данные чаще чем раз в 5 секунд.

Поэтому и родился такой себе регистр-стэк, куда будут складываться данные о изменившихся остатках товаров - которые не чаще чем раз в 5 секунд будут отправлены на сервер порциями не превышающими порогового (заранее установим) значения по количеству записей в порции

(23) Т.е. веб-сайт имеет наглость ставить свои ограничения, а из 1С мы должны сделать СРВ? За-ме-ча-тельно.

(23) То есть регистр специальный и в него пишутся только изменения - тогда в чём проблема - выбираться должно быстро, только регистр нужно не забывать чистить.

(19) 5 секунд - это не обязательно. Это просто минимально-возможный интервал по договоренности с разработчиками сайта.
Очень даже может быть что будет и больше. Но если частота изменения данных в 1С начнет повышаться - то придется переходить на 5 сек. Поэтому и спрашиваю, если припрет и придется перейти на такой интервал - как быстро все упадет, и что сделать что бы предотвратить падение.

(25) В регистр будут писаться не все подтряд товары. Да и выбирать из него будет по определнному флагу (если остаток у товара изменялся)
Но насчет чистки - тоже идея хорошая. Очень возможно что будет регламетное подчищающее его.

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

(26) 1С не гарантирует время реакции фонового задания, это не система реального времени. Я бы даже круче сказал - использование 1С для реал-тайм фронт-офиса почти всегда заводит в тупик.

(24) К сожалению - без веб-сайта и в 1С смысла нет. Это таки интернет магазин, и именно сайт кормит всех, а 1С хоть и выполняет львиную часть работы по учету, но сама продажами не занимается. Поэтому и приходится терпеть капризы разработчиков сайта.

(27) Чистить должен тот же, кто и читает, так как иначе регистру быть подчищенным до чтения.

В общем делалось такое. Складывались тупо товары и все. Если товар повторился в другом документе - не добавляем. А остатки брались при процедуре выгрузки для списка товаров (одним махом или как угодно).

(30) А сайт сам не может "проявлять интерес", так как может оказаться, что изменения остатков на сайте в данный момент не нужны.

Я все-таки за прямую запись во внешнюю БД из подписки. Можно промежуточную БД. Это отожрет на порядок меньше ресурсов.

(32) Именно, только я еще и остатки сразу фиксирую, что бы не тратить время на выборку через всякие там "ТоварыНаСкладахОстатки".

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

Но, там на горизонте вызревает другая проблема. Если запросов в минуту будет несколько тыщ?! Что будет с вебсервисом 1С справится ли он с нагрузкой... и не придется ли мне вводить аналогичное ограничение типа "запрос не чаще чем раз в 5 сек".

Но пока будем двигать в направлении из 1С на сайт.

(35) Как ты можешь фиксировать остатки если они каждое мгновение меняются? Значит каждый раз сверять с актуальными, да еще и для всего списка (в т.ч. и ранее проведенных).

(34) Спасибо за мнение. Учтем. Есть альтернативный вариант решения состоящий в том что из подписки генерировать файлы складывать их в каталог... а сайт будет их забирать сам когда решит что ему это надо.
Но это запасной вариант.

(+34) Причем именно так я и решал подобную задачу.
Только у меня запись в таком стеке хранила еще XML-описание изменений.
(36) Это тоже не выход. На сайте д.б. актуальные остатки без какого-либо оформления заказа. Хотя бы для "товар есть на складе".

(37) Если проведение документа меняет остатки товаров, то сразу при проведении их можно и менять, так как на момент проведения они уже посчитаны - нужно только куда-то записать.

(37) В регистре, хранится информация о значении последнего остатка после последнего изменения.
Сравнивать надо не по всем, а только по тем товарам которые были в документе который только что записался/провелся.

И даже если два документа в один момент времени попытаются изменить остатки по одному и тому же товару - это будет заблокировано на уровне транзакций при обработке проведения.
Блокировки там и все такое...

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