ss
Даже заморачиваться не буду на 1с с такой задачей.
Size: a a a
2021 February 20
ss
Прокси на любом другом языке c++, java, c# и после приёмки сообщения отдам его в 1с по http
ss
Вместо программирования будет изврат в 90% костылей в платформе и нахождения каких то обходов
ss
Плюс если не достаточно 1000 записей в секунду в тучу потоков, которые надо разбирать, а потом удалять... Справочники ой как быстро удаляются
ПМ
Не всегда нужно удалять очень частотная операция. Выше был пример лог.изменения реквизитов. 1000 новых записей в сек это в современной ситуации уюе не редкость. 700 активных операторов и плюс десяток обмееов и в базе колво собатий для лога изменений будет овер 1000 сек
ss
Задача то какая практическая? Часто часто писать по одному символу? Или логировать 700 операторов которые каждую секунду записывают справочник, изменения реквизитов которого надо логировать? 28800 элементов один оператор за рабочий день обрабатывает. Круто!
ПМ
Умозрительный эксперимент. Стоит ннкий датчик / телеграф / модем он выдает с разной скоромтью букву. Создайте в 1с структуру для приема этого сообщения. Сколько знаков в секунду от одного датчика вы максимум прочитаете, а если датчиков будет 10
См выше. Что у тебя за датчики и что за буквы (события) требуется схватить. Сам подставь что ближе (коллцентр, конвеер заводской, шина обмена и т.п). Математически задача сводится к созданию структуры способной принимать и сохранять в секунду x сообщений с n параллеельных источников.
JD
sdf1979 sdf1979
Все ж самая быстрая запись в РС НаборЗаписей.Записать(Ложь), в котором одно измерение Число(14,0) = ТекущаяУниверсальнаяДатаВМиллисекундах(). Дальше скорость уже будет зависить от объема записываемых данных в ресурсах. Затем если есть затык - то меняли fillfactor в MS SQL на 50%.
Плохое измерение. Не ловил ошибку вставки (при высокой частоте) из-за повторяющегося значения в мс?
ss
John Doe
Плохое измерение. Не ловил ошибку вставки (при высокой частоте) из-за повторяющегося значения в мс?
Нет. Не ловил. Хватило. Обычно делаю два измерения для очереди на РС. Число 14 для порядка очереди и число 11 индексируемое для удаления. Гранулярность удаления опытным путем от нагрузки выбираем.
NM
sdf1979 sdf1979
Все ж самая быстрая запись в РС НаборЗаписей.Записать(Ложь), в котором одно измерение Число(14,0) = ТекущаяУниверсальнаяДатаВМиллисекундах(). Дальше скорость уже будет зависить от объема записываемых данных в ресурсах. Затем если есть затык - то меняли fillfactor в MS SQL на 50%.
Уже писали же, что поведение поменяли... И ложь больше так не ускоряет.
NM
Кому интересно - вот тред обсуждения https://partners.v8.1c.ru/forum/t/1853067/m/1853091
ПМ
Уже писали же, что поведение поменяли... И ложь больше так не ускоряет.
👌 "ложь не ускоряет" в цитаты
A
Уже писали же, что поведение поменяли... И ложь больше так не ускоряет.
Вот спасибо тебе! "А мужики то незнали"(с)
ss
Screenshot_1.png (1016×650)
ss
8.3.17.1496
JD
Вся соль в совместимости
ss
Не использовать
АМ
Простите за беспокойство :) Используем схему разработки, похожую на гит флоу. Соответственно, есть дев ветка, от нее периодически отходят релизы и объединяются с мастером. На коммит в релизе запускается gitlab pipeline. Когда только начинали у программистов периодически были проблемы с пониманием гита соответственно подстраховывались хранилищем и после создания очередной релизной ветки для надежности выгружали в нее конфигурацию хранилища (типа синхронизации), появлялся новый коммит и стартовал пайп. Все было хорошо за исключением косяков программистов. Сейчас косяков практически не стало и при синхронизации выясняется что хранилище и ветка соответствуют друг другу. Получается что коммитить нечего и приходится делать технический коммит чтобы стартовать пайп. А кто как выходит из этой ситуации? У меня альтернатива пока только тэги вешать как в мастере.
NG
Александр Медведько
Простите за беспокойство :) Используем схему разработки, похожую на гит флоу. Соответственно, есть дев ветка, от нее периодически отходят релизы и объединяются с мастером. На коммит в релизе запускается gitlab pipeline. Когда только начинали у программистов периодически были проблемы с пониманием гита соответственно подстраховывались хранилищем и после создания очередной релизной ветки для надежности выгружали в нее конфигурацию хранилища (типа синхронизации), появлялся новый коммит и стартовал пайп. Все было хорошо за исключением косяков программистов. Сейчас косяков практически не стало и при синхронизации выясняется что хранилище и ветка соответствуют друг другу. Получается что коммитить нечего и приходится делать технический коммит чтобы стартовать пайп. А кто как выходит из этой ситуации? У меня альтернатива пока только тэги вешать как в мастере.
а этот технический коммит - результат мержа релиз-ветки в мастер или просто пустой коммит поверх одной ветки с одним родителем?