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

(0)писал интеграцию на раббит эмкю, на средненьком сервачке отрабатывалось порядка 30-50 док/сек с проведением по 4-5 регистрам

но это по отношению к вам пальцем в небо, т.к. недостаточно вводных данных

(0) зависит от железа

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

Хотя меня немного смущает постановка - я так понял, что уже есть система розничных продаж в 1с и надо в сап отдавать документы. Тогда причем здесь проведение?

(2) Ну железо можно будет выбить норм под это дело.
Меня больше сама 1С беспокоит, она же при проведении блокирует частично регистры, не получится, что просто физически невозможно будет провести больше чем N документов в 1 сек, по причине взаимоблокировок.
+ Типовой док долго проводится, думаю надо будет создавать кучу фоновых заданий?

(4) Ну если можешь выбить, так выбей и не парься вообще.

(0) Нереально...

(3) там целая россыпь разных типов документов
Хотят именно через типовые документы. Но я тоже склоняюсь к общему документу, который нужные проводки рисует. Заодно и списки типовых захламлять не будет.

(3)Наоборот, в сап есть куча доков, которые нужно отдать в новую Одинэску. т.к. переходят частично на 1С - импортозамещение)))

(7) С САП на 1С? Правда чтоли?

(8) Угу, частично.

Здесь проблема в следующем: моменты ускорения
1. Работать только на сервере (фоновыми заданиями)
2. В несколько потоков (соответственно иметь механизм разделения на потоки) - по опыту при количестве потоков больше 50 (по некоторым задачам 100) наблюдалась деградация производительности.
3. Как вариант - запись и проведение делать разными потоками.

Но очень (точнее ОЧЕНЬ) не хватает возможности писать набор регистра накопления сразу по нескольким регистраторам.

Ну и большой вопрос - типовыми документами в УПП? :)

100 документов в секунду в 1С? Сегодня что, пятница?

Т.е. Из сапа надо документы грузить в 1с и там проводить 100 в сек? Не реально: будет перехлест по клиенту, по номенклатуре - будут блокировки. Надо упрощать, оптимизировать конфу и делать нагрузочный тест.

Интересная задачка.

И как вариант - добавляется параллельный учет (регистр, можно сведений, документы) в который делается загрузка максимально быстро + переброска из этого параллельного учета в типовые документ + доработка отчетности чтобы учитывался новый контур. Это может дать еще прирост производительности, но это, имхо, самый крайний вариант.

(14) как вариант - объединять документы. наверняка, там есть общие поля. Добавляйте ИД документа САПа в табличную часть документа 1С

А каждому пользователю нужнА актуальная база в течении часа, например? Если нет, то в специальной центральной служебной базе проводить а потом в пользовательскую периферийную полным обменом скидывать документы с движениями.

+14 как вариант мы делали - писали в промежуточный регистр сведений и затем отдельной джобой разбрасывали по типовым документам. Но там дорабатывалось 2 отчета, которые нужны были людям работающим онлайн. Остальные работали с данными за предыдущий период.
Так легко достигали скорости порядка 500 тысяч простых операций в час (приход/расход). Потом еще пост обработка.

100 доков в секунду это что типа чеки онлайн из розничных точек грузить и проводить?

может все таки объединять? вместо кучи документов делать сводные (аналог закрытие смены/отчет о розничных продажах)

(17) кстати да это вполне вариант, быстрая загрузка данных в регистры, затем медленная постоянная обработка в фоне

+17 и с учетом 16 - вариант - база с актуальными данными - быстрая + база с актуальностью за предыдущий день (например), где данные свернуты.
Т.к. вы просто при таком объеме данных начнете захлебываться: 100 документов в секунду, это 2,88 млн операций за 8 часов. Не ужас, ужас - но немало

(17) вы это делали на типовой конце? В типовых много лишних телодвижений, что сильно замедляет проведение.

(0)кста 100 док/сек это пик?

(21) Нет. Самописка. Там спокойно на простых документах выходили на 200 в секунду.

Хотя есть еще 1 вариант - но он, на мой взгляд, самый поганый - прямая запись в базу каким-нибудь балк инсертом.

(24) если только в какую-то промежуточную базу, не предназначенную для интерактивной работы пользователей

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

(17) Да, копия данных из сапа аккомулируется в рег. сведений, и оттуда будет проводится. Копирование и проведение это отдельные задачи.
(22) Надеюсь, но похоже что нет, в праздники может быть и больше.
(18) Там россыпь и реализации и возвраты и перемещения и прочее прочее прочее

+26 - собирать документы даже одного типа можно разными фоновыми. А вот с проведением уже интереснее.
Но еще раз замечу - делать это в типовой... Ну здесь могу только удачи пожелать...

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

В общем я бы начал с того - кому и для чего нужны данные онлайн.

(0) А у вас 100 доков в секунду непрерывно круглые сутки должны проводиться или все-таки есть тайм-ауты?

(0)
да, будет держать без проблем.

(30) это пик, если "размазать" проведение по дню то меньше кончено будет.
Но все равно много. Схемы надо те же юзать.

Еще сразу посмотрите тему 24-7. Есть или нет. Это другой вопрос: если работа должна быть 24 на 7, то когда делать всякие обновления и прочие регламентные действия.

(0) А движения нужны сразу? Может документы ставить в очередь и проводить по очереди? Или отложенное проведение.

(0) Для таких задач и нужны крупные ЦКП. Выбирайте и несите деньги. Пусть отрабатывают.

(0) Да легко, все в Операцию Бух и взлетит. Это типовой документ.

В (0) ошибка, похоже. "Проведение 100 документов в секунду" написано, наверное, "Проведение документа за 100 секунд"? Уж если с САП-а перенос имеется в виду. Да и то, я ещё не видел систем на 1С, проводящих документ дольше 10-ти секунд, а за 10 секунд - это очень нагруженная система была, хламом всяким.

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

мысли вслух...
для оформления одного чека нужно хотя бы 20 секунд в среднем (поздороваться, набить одну позицию, получить оплату, распечатать чек, отдать сдачу и чек). Для создания нагрузки 100 чеков в секунду соотвественно нужно минимум 2000 касс. Причем на каждой кассе должна быть очередь, что бы работали беспрерывно.
Пусть в среднем в одном магазине одновременно работает 20 касс - получаем розничную сеть в 100 магазинов на минимум 20 касс каждый.
Или как вариант сеть в 1000 магазинов на 2 кассы каждый.
И это только при условии короткого чека. Если рассматривать магазины с широким ассортиментом, то касс должно быть в разы больше.

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

Более правдоподобным кажется вариант что речь идет про сеть в 100 касс в целом и теоретически возможная пиковая нагрузка 100 одновременно проведенных чеков. Тогда почему "в секунду"? Можно ставить задачу про 100 чеков в 1 милисекунду или микросекунду :)

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

(0)
Я реализовывал подобное, но на 7.7. В базе было 20 активных пользователей и 5000+ чеков в сутки (точнее за 10 часов рабочей смены).
Нагрузочное тестирование показало маскимальную нагрузку 5 чеков в секунду без работы других пользователей. То есть до 200к чеков за смену. На практике таких нагрузок никогда не было.
Из подводных камней - блокировки.