Притер в базе 100 организаций. Будет ли разница в производительности сервера 1с если сделать 100 планов обмена, один план на организацию. На одном плане данные регистрируются по одной организации, только один вид документа. Или 1 план обмена для всех организаций. И это должно выполняться регламентно.
Повлияет ли это на производительность записи документа который будет регистрироваться?
Есть у кого в практике 50-100 планов обмена или более. Какие сюрпризы могут быть.

Повлияет.
И то, и другое замедлит.

(0) много ли документов каждый день?

(0) 100 Планов обмена это изврат и неумение работать с планами обмена.

(0)Если я правильно помню, фильтр по организации выставляется в момент отправки а не в момент регистрации. Что быстрее зарегистрировать один документ в 100 планах обмена или в 1?

(4) в ут 11 не так

(4) Нет, фильтр ставится именно в момент записи.
В типовых так.

// Повлияет ли это на производительность записи документа который будет регистрироваться?

записываться в базу в регистры типовые или записываться в таблицах регистрации измененных?

хрен редьки не слаще, если авторегистрация будет включена для всех вариантов одинаково

(4) объектами в этом контексте будут не планы, а узлы планов обмена, примерно или точно совпадающие с количество разных баз данных. Если у тебя 100 узлов, то как ты их не раскладывай, вдоль или поперек, их меньше не станет

другое дело, если контекст задачи подразумевает одни и теже данные раздать множеству получателей параллельно. Тогда выгрузи один раз, а загружай столько, сколько нужно. Но надо продумать, как заставить адресата думать, что это посылка была ему, а не соседней базе.

(6)Значит спутал с БСП.
(9)Если нет принципиальной разницы, то как минимум админить 100 планов по 1 узлу бкдет сложнее чем 100 узлов в одном плане.

а если нужно еще 1 узел добавить, так это конфу чтоли обновлять?

(10) В БСП тоже фильтр (по значениям реквизитов узла, например по организации) при регистрации применяется, а не при отправке

Разумеется один плана обмена на все организации базы.
Регистрация изменений - тоже общая. Она и будет регистрировать изменения по узлам (за счет настройки узлов).
В чём плюс? Хотя бы в том, что при добавлении новой организации не нужно изменять конфигурацию - достаточно добавить новый узел в план обмена и настроить ему фильтр.

Ваш к.э.п.

(0) Вы ещё забыли про 100 сеансов обмена сообщениями и 100 настроек автоматизации обмена данными.

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

(14) так блокируются только свои таблицы

(0) Если документов (объектов обмена) разумное количество, то делать один план обмена.

Если объектов обмена - до хрена и больше, то 100 планов обмена

(15) Что значит "свои таблицы"? Таблица регистрации изменений у каждого вида объектов одна единственная для всех планов/узлов. И поэтому один объект не может одновременно участвовать в нескольких сеансах обменов.

(17) объект блокируется на момент выборки из таблицы изменения, не время всего обмена.
Ничего страшного

Может не правильно выразился. Я имел ввиду план обмена 1, а элементов(узлов) 100 или 1.

(19) Сколько распределенных баз планируется? Столько и узлов в плане обмена должно быть.

(20) Возможен вариант:
ЦБ - 10 узлов по 10 организаций - в каждом подчиненном узле свои 10 узлов по 1 организации.

для обмена документа только 1 вида проще свой обмен написать

(19)Нихренасе ты "неправильно выразился". Тут такая дискуссия развернулась...

(23) Извиняюсь.

(21) Не распределенная она, просто обмен в одну сторону, с одной базы в 100 баз. В этих 100 баз только 1 организация.
Для этого планируется создать 100 узлов.
На счет регламентного задания, посмотрел, вроде можно в 1 сценарий запихать все 100 узлов.
И вопрос в том, как это скажется на производительности.
Для каждого узла будут регаться к отправке только документы одной организации. На каждую организацию по узлу.

(24) Такое впечатление что "гаражный автомеханик" пытается планировать разработку и производство новых авто...

(25) Что тут нового? Так делают, но более 8 узлов я не видел.

(26) 180+ не хошь узлов? В 2008 году еще

(27) В смысле у тебя была база со 180+ узлами?

(14) Так можно выбрать список объектов для обмена и выгружать их уже потом - вне сеанса обмена.

(28) Угу еще на 8.1. Пойми "узел" это по сути отдельная база (филиала, подразделения, магазина, отдела и т.д.).

А "план обмена" это правила передачи инфы между узлами.

(30) Да это я понимаю, просто не правильно назвал.
И какие были неприятности, сложности при 180 узлах?

(31) Обмен по всем узлам идет долго, на ночь обычно запускали вечером.

(32)+ Пришлось огромный "справочник Пациентов" сделать отдельный обмен через DBF файлы с синхронизацией по УИД.
Справочники эти раз в месяц "обновляли" а там до полуляма записей по сути перезаписаны.

(33) Почему так пришлось?
только пациенты черед дбф, всё остальное через план обмена?

(34) Нет справочник Пациентов через план обмена тоже мог уходить, но слишком медленно это было бы.
Банально куча элементов (полляма) обновилась разом и каждый должен зарегаться в плане обмена (поэтому при загрузке данного справочника грузил без регистрации).
Если любой из этих обновленных/загруженных открыть и нажать "Записать" то этот элемент штатно уйдет через обмен.
Но чтобы не за$ирать штатный обмен была отдельный пункт меню для загрузки справочника через фтп.

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

так вот, когда введено это самое НСИ, то под него выделяем особый узел, юзера, с правами на редактирование данных НСИ даже в нем не сидят. Но этот узел НСИ однократно получает всю обновленную инфу и спокойно, без воздействия на свою работу множества юзеров, эту самую выбранную НСИ раздает своему множеству читателей, но не писателей. С учетом современного развития можно раздавать и не обязательно в режиме выгрузки каждому, а может быть и такое, что на чтение читатель будет к базе цеплятся в веб-сервисе. НО !!! в этой базе никаких юзеров практически нет. Только загрузить инфу от центрального офиса или еще откуда-то, перечитать ее, перерегать под новое правила и отдать. все!

для того, чтобы проще было принять решение о том, сколько планов обмена создавать, общее правило такое: один план обмена - это один комплект правил.
То есть, если задача решается посредством одного комплекта правил, то достаточно одного плана обмена.


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

в этой ветке даже голосовалка наркоманская

Документы это хорошо. Но помимо документов наверняка есть справочники (контрагенты, номенклатура)

И получается вопрос регистрировать ли 1 раз или 100 раз

(40) ну я к тому и написал про введение НСИ. Там хоть и раскрывается аббревиатура "нормативно-справочная информация" но на практике внедрения уже готовых больших систем туда попадают не только справочники, но и другие разные данные. В конце концов, технически по элементам справочника могут быть заданы нормативные состояния, которые двигаются нормативными документами по нормативным регистрам сведений :)