доброго вам утра, уважаемые специалисты.
в общем, есть задача критическая по скорости выполнения.
она выполняется в несколько потоков, потоки сбрасывают протоколы выполнения в хранилище системных настроек. а основной поток, который опрашивает вспомогательные с периодичностью льет логи во внешний сервис протоколирования.
сейчас для передачи сообщений протоколов между фоновыми заданиями и основным я использую хранилище общих настроек. а его методы тормозные, т. к. вполне возможно, что данное хранилище хранится в таблицах СУБД. по хорошему, мне надо выделить какую-то область в памяти сервака для каждого фонового задания и лить туда массивы с сообщениями протоколов напрямую. это возможно вообще в 1С?
заранее благодарю за помощь.

а нельзя все потоки заставить лить лги во внешний сервис и нее мучаться с синхронизацией?

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

https://sourceforge.net/projects/imdisk-toolkit/
хоба, allocate memory dynamically, то что нужно.

(0) вк как вариант

(4) да, но что будет быстрее - внешняя компонента и ее отладка, или запилить RAMDrive на какой-нибудь exfat?

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

для передачи данных "наверх"

(7) это типа быстрее? откуда я знаю что сообщения фоновых не хранятся где-нибудь в таблицах на диске?

(8) ну, я хз, конечно, но в многопоточном тесте данные от 100 потоков вполне себе быстро приходят в основной поток.

вроде лони в rmngr хранятся

*они

(10) то есть в памяти процесса, да?

(12) да

(2) а обращение основного потока разве не затрачивает это же время на обращение к апи? Только дополнительно затрачивается время на запись в хранилище и время на опрос этого хранилище и прочую ерунду?

В ФЗ "Сообщить" + ФЗ.ПолучитьСообщенияПользователю извне

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

(16) можно вынести в отдельный поток отправку сообщений или вообще в отдельное регл. задание

(17) но ведь время работы с внешним сервисом тогда не изменится? Я не могу понять проблема со скоростью появления данных во внешнем сервисе или в формировании на стороне 1с перед отправкой во внешний сервис

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

(18) проблема в обращении к хранилищу системных настроек, которое жутко долго отрабатывает

(20) тогда отправка прям из фонового задания чем не устраивает, ведь тогда нету операции помещения считывания. Сразу отправил в сервис.
Тоесть время работы это
Время формирования протокола + время отправки

1)Сформировал -отправил(1 секунда)
2)сформировал - положил-открыл-отправил(та же секунда)

в (1) как по мне решение этой проблемы

(20) да и проблема это то что обращение к APi 1 секунда. 1 секунда это время ответа сервиса на отправленный ему протокол(набор протоколов)? или время подключения к нему?

(20) Это хранилище в СУБД лежит. Можно через сеансовые данные попробовать, они в файле лежат где каталог сервера 1С.

(22) время подключения, причем в фон это дело не отправить, будет медленнее.

(23) что за сеансовые данные? не понял

(25) ПоместитьВоВременноеХранилище(<Данные>, <Адрес>)

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

(27) И следом: Данные, помещенные в фоновом сеансе в хранилище по сформированному в родительском сеансе адресу, сразу после помещения становятся недоступными в фоновом сеансе.

+(28) Пул адресов закинуть. Закончились адреса, завершать фоновое и начинать новое. Выкручиваться, как обычно.

(26) Где физически хранятся данные, помещенные во временное хранилище?

(30) that's the right question, my friend.

(28) Для обмена в реальном времени (пока ФЗ не завершено) это не подходит

(30) (31) https://its.1c.ru/db/metod8dev/content/5860/hdoc

(33) Спасибо за ссылку

Так что сеансовые данные, в т.ч. и временное хранилище, _всегда_ сбрасываются на диск

(35) а сообщения пользаков?

сообщения пользаков в фоновом сеансе - это тоже на диске?

(36) Конечно же никуда на диск не сбрасываются, хранятся в памяти "менеджера" сеанса, т.е. рпхоста

(38) ясно, спасибо большое за технический ликбез.

(38) Разве менеджер кластера не rmngr? Как они могут не сбрасываться на диск, если rphostы, например, запущены на разных компьютерах входящих в кластер?

(40)
1. Хз почему ты о менеджере кластера спрашиваешь.
2. На кластере с рабочими серверами на разных хостах не проверял.
На "обычном" сервере приложений (с одним рабочим сервером): занимаемая рпхостом память от сообщений в ФЗ пухнет, а когда клиент запрашивает эти сообщения, то начинается активность рпхоста по сети, а на диске активности никакой. После завершения ФЗ занимаемая рпхостом память, увеличенная на размер сообщений, _иногда_ уменьшается.

Я уже в другой теме говорил,потоки в обрпботчики http-запросов,и опрашивать их асинхронно,тогдп на диск ничего не попадет,и ответ будет обрабатываться сразу,как поступит.
Если операционная система семейства windows,то для двух процессов общую память можно сделать двумя путями
или проецирование файла в память(если файл не указывать, о проецируется файл подкачки),то есть,хоть это и будет общая память,но это все равно будет файл на диске.
запись из одного процесса в другой в режиме отладки(но тае обычно никто не работает).

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