Имя: Пароль:
1C
1С v8
Можно ли выполнять регламентное задание с расписанием "каждые 5 секунд"
,
0 mvgfirst
 
05.02.14
23:00
По идеологии прикладной задачи предполагается вызов регламентного задания с частотой от 5 секунд.
Т.е. чаще чем какждые 5 секунд вызываться не планируется, но реже может.

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

Признателен за Ваши советы (адекватные разумеется)
1 Asmody
 
05.02.14
23:05
(0) смотря что ты там в эти 5 секунд делаешь.
2 xReason
 
05.02.14
23:08
(0) Если будет вызывать 6 сек. ТО все сдохнет к чертям собачим
3 sanja26
 
05.02.14
23:11
ВыбратьИзменения блокирует всю таблицу регистрации по узлу
4 sanja26
 
05.02.14
23:12
а для остального без разницы
5 mvgfirst
 
05.02.14
23:21
(1) (2) Собираюсь выполнить запрос, к регистру сведений, получить результат, упаковать в XML файл, и отправить на веб-сервер.
Предположительно должен уложиться в 5 секунд. Одно смущает... могу не успеть дождаться пока сервер вернет ответ.

А если поставить параметр "Завершать через" - равным 4 секундам. Это поможет. даже не смотря на то что сервер может не ответить?
6 Либерал
 
05.02.14
23:24
может быть пусть лучше веб-сервер по необходимости запрашивает данные у веб-сервиса 1с?
7 mvgfirst
 
05.02.14
23:25
И еще вариант, могу ли я запустить 4 одинаковых Регламетных задания с интервалом запуска 20 секунд и сдвигом по времени старта 5 секунд относительно старта предыдущего.
Решит ли это проблему, или это "те же яйца - только в профиль"?
8 mvgfirst
 
05.02.14
23:27
(6) Необходимость формирует 1С... а не веб-сервер. Веб сервер тоже пихает в 1С информацию - если что-то происходит у него. (назовем это - действием пользователя)
9 Torquader
 
05.02.14
23:28
А регистр как часто обновляется ?
10 mvgfirst
 
05.02.14
23:32
(9) Регистр будет обновляется при каждом проведении документа содержащего Номенклатуру и Склад. Но при условии что после проведения остаток изменился.
Говоря простым языком при каждом списании оприходовании товара - регистр будет обновляться.
11 КонецЦикла
 
05.02.14
23:35
Что там за регистр такой сведений?
Я обычно складывал в свою таблицу SQL. А сторонняя приблуда-робот-1С мониторила ее содержимое (с признаком обработки или с удалением). Я думаю что не восьмерке, да еще и с коннектом к серверу не взлетит каждые 5 секунд.
12 КонецЦикла
 
05.02.14
23:37
Может замутить ср-вами SQL?
13 Diversus
 
05.02.14
23:37
Фоновое задание может иметь ключ – любое прикладное значение. Ключ вводит ограничение на запуск фоновых заданий – в единицу времени может выполняться только одно фоновое задание с определенным значением ключа и заданным именем метода фонового задания (имя метода состоит из имени модуля и имени процедуры или функции). Ключ позволяет группировать фоновые задания, имеющие одинаковые методы, по определенному прикладному признаку с тем, чтобы в рамках одной группы выполнялось не более одного фонового задания.
14 Torquader
 
05.02.14
23:38
(10) Просто, есть мнение, что задание должно запускаться в момент проведения документа, то есть тогда, когда в регистр записали. При записи сбрасывать флаг обновления, чтобы видеть, что никто в момент исполнения ничего не записал, а потом при завершении его проверять - если больше записи нет, то не стоит каждые пять секунд "дёргать" базу.
15 Diversus
 
05.02.14
23:39
Заполните реквизит "Ключ" в свойствах регламентного задания и фоновое задание будет выполняться в одном экземпляре.
16 xReason
 
05.02.14
23:39
(10) ИМХО 5 сек опасно для таких вещей.
Если в регистр будет идти запись, то лучше не рисковать.

Я бы поменял логику действий.
Если уж совсем все плохо, то придумай, например константу (есть такой термин PID) .
Перед началом операции проверяй PID = 0, если да, то ПИШУ в него 1 и запускай процесс. Когда все сделал пиши туда опять 0.
Если вдруг запустится 2ой задание и увидит там 1 в PID. То просто выключиться
17 mvgfirst
 
05.02.14
23:40
(12) Вот как раз неохота прикручивать что-либо стороннее. Крайне неохота. Ровно как и писать напрямую в базу данных сайта (как бы тут не кричали что это во сто крат быстрее любых других методов)
18 КонецЦикла
 
05.02.14
23:40
(14) Лучше уж дергать... прочитать табличку небольшую общую быстрее (в целом), чем что-то выполнять при проведениии.
19 Сисой
 
05.02.14
23:42
(0) Объясни, плиз, зачем 5 сек? Почему нельзя 10?
20 КонецЦикла
 
05.02.14
23:43
(17) У меня был робот-1с. Он постоянно висел, т.е. ничего не стартовало. Напрямую тоже писал в MySQL, конечно быстрее.
21 Torquader
 
05.02.14
23:43
(18) При проведении мы кидаем флаг, что нужно "дёрнуть" и выставляем команду исполнения регламента. Регламент потом запускается и "дёргает".
Если никто не провёлся, то запуск регламента проверяет флаг, меняет интервал своего исполнения на какое-то большое значение (или просто выключает регламент) и завершается.
22 Сисой
 
05.02.14
23:43
Это интернет-магазин, что ли?
23 mvgfirst
 
05.02.14
23:43
(14) Проведение документов (в теории) может происходить чеще чем 1 раз в 5 секунд.
На веб сайте поставили ограничение (логическое - на всякий) - не пихать в него данные чаще чем раз в 5 секунд.

Поэтому и родился такой себе регистр-стэк, куда будут складываться данные о изменившихся остатках товаров - которые не чаще чем раз в 5 секунд будут отправлены на сервер порциями не превышающими порогового (заранее установим) значения по количеству записей в порции
24 Сисой
 
05.02.14
23:45
(23) Т.е. веб-сайт имеет наглость ставить свои ограничения, а из 1С мы должны сделать СРВ? За-ме-ча-тельно.
25 Torquader
 
05.02.14
23:46
(23) То есть регистр специальный и в него пишутся только изменения - тогда в чём проблема - выбираться должно быстро, только регистр нужно не забывать чистить.
26 mvgfirst
 
05.02.14
23:46
(19) 5 секунд - это не обязательно. Это просто минимально-возможный интервал по договоренности с разработчиками сайта.
Очень даже может быть что будет и больше. Но если частота изменения данных в 1С начнет повышаться - то придется переходить на 5 сек. Поэтому и спрашиваю, если припрет и придется перейти на такой интервал - как быстро все упадет, и что сделать что бы предотвратить падение.
27 mvgfirst
 
05.02.14
23:47
(25) В регистр будут писаться не все подтряд товары. Да и выбирать из него будет по определнному флагу (если остаток у товара изменялся)
Но насчет чистки - тоже идея хорошая. Очень возможно что будет регламетное подчищающее его.
28 КонецЦикла
 
05.02.14
23:48
Мне даже кажется, что какой-то триггер или на худой конец кривой код 1с исполнился бы быстрее для безусловной записи измененных товаров, чем встроенная проверка (а изменились ли остатки)
Получается что жертвуем производительностью системы для обеспечения оперативного обновления для неизвестно кого (кто еще и страницу не обновил).
29 Сисой
 
05.02.14
23:49
(26) 1С не гарантирует время реакции фонового задания, это не система реального времени. Я бы даже круче сказал - использование 1С для реал-тайм фронт-офиса почти всегда заводит в тупик.
30 mvgfirst
 
05.02.14
23:49
(24) К сожалению - без веб-сайта и в 1С смысла нет. Это таки интернет магазин, и именно сайт кормит всех, а 1С хоть и выполняет львиную часть работы по учету, но сама продажами не занимается. Поэтому и приходится терпеть капризы разработчиков сайта.
31 Torquader
 
05.02.14
23:49
(27) Чистить должен тот же, кто и читает, так как иначе регистру быть подчищенным до чтения.
32 КонецЦикла
 
05.02.14
23:49
В общем делалось такое. Складывались тупо товары и все. Если товар повторился в другом документе - не добавляем. А остатки брались при процедуре выгрузки для списка товаров (одним махом или как угодно).
33 Torquader
 
05.02.14
23:50
(30) А сайт сам не может "проявлять интерес", так как может оказаться, что изменения остатков на сайте в данный момент не нужны.
34 Сисой
 
05.02.14
23:51
Я все-таки за прямую запись во внешнюю БД из подписки. Можно промежуточную БД. Это отожрет на порядок меньше ресурсов.
35 mvgfirst
 
05.02.14
23:51
(32) Именно, только я еще и остатки сразу фиксирую, что бы не тратить время на выборку через всякие там "ТоварыНаСкладахОстатки".
36 mvgfirst
 
05.02.14
23:54
(33) Я все же надеюсь, что до живу до того момента, когда разработчики сайта прислушаются ко мне и сделают запрос со стороны сайта к веб-сервису 1С и будут спрашивать остатки при оформлении заказа.

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

Но пока будем двигать в направлении из 1С на сайт.
37 КонецЦикла
 
05.02.14
23:54
(35) Как ты можешь фиксировать остатки если они каждое мгновение меняются? Значит каждый раз сверять с актуальными, да еще и для всего списка (в т.ч. и ранее проведенных).
38 mvgfirst
 
05.02.14
23:55
(34) Спасибо за мнение. Учтем. Есть альтернативный вариант решения состоящий в том что из подписки генерировать файлы складывать их в каталог... а сайт будет их забирать сам когда решит что ему это надо.
Но это запасной вариант.
39 Сисой
 
05.02.14
23:55
(+34) Причем именно так я и решал подобную задачу.
Только у меня запись в таком стеке хранила еще XML-описание изменений.
(36) Это тоже не выход. На сайте д.б. актуальные остатки без какого-либо оформления заказа. Хотя бы для "товар есть на складе".
40 Torquader
 
05.02.14
23:57
(37) Если проведение документа меняет остатки товаров, то сразу при проведении их можно и менять, так как на момент проведения они уже посчитаны - нужно только куда-то записать.
41 mvgfirst
 
05.02.14
23:58
(37) В регистре, хранится информация о значении последнего остатка после последнего изменения.
Сравнивать надо не по всем, а только по тем товарам которые были в документе который только что записался/провелся.

И даже если два документа в один момент времени попытаются изменить остатки по одному и тому же товару - это будет заблокировано на уровне транзакций при обработке проведения.
Блокировки там и все такое...
42 Torquader
 
05.02.14
23:58
Потом, для информации о наличии товара достаточно того, что товар сегодня был, а вот когда формируется и подтверждается заказ, можно спросить в 1С (так как в ней наверняка захотят этот заказ увидеть) - сомневаюсь, что за пять секунд будет несколько тысяч заказов в состоянии подтверждаю.
Закон Брукера: Даже маленькая практика стоит большой теории.