Эффективные приемы разработки

07.04.21

Разработка - Математика и алгоритмы

На Infostart Meetup Ekaterinburg.Online выступил Сергей Наумов – руководитель центра аналитики и консалтинга WiseAdvice. Сергей поделился с коллегами приемами разработки, которые помогут избежать потенциальных проблем при реализации сложных проектов.

План доклада

 

 

В ходе доклада:

  • Поговорим о возможности кэширования внутри сложных алгоритмов. Забегая вперед, скажу, что в типовых решениях есть спагетти-код. Не всегда удается эффективно “прокинуть” кэш через все эти процедуры.

  • Рассмотрим многопоточную обработку – это модная тема, которая здорово ускоряет код.

  • Обсудим возможности получения данных с помощью СКД.

  • Я поделюсь примерами с предыдущих проектов. За предшествующие докладу два года накопилось много интересных проектов и кейсов – на реальных примерах посмотрим, как я решал те или иные задачи.

 

Кэширование внутри сложных алгоритмов

 

 

Первое, что мы рассмотрим – это кэширование внутри сложных алгоритмов.

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

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

 

 

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

Пару слов расскажу про базу, которую я сделал для иллюстрации примеров. Это упрощенный пример одного из предыдущих проектов, где я столкнулся с производительностью типового решения. Столкнулись очень жестоко, долго оптимизировали – пытались сделать так, чтобы клиент получил планы производства не через неделю, а хотя бы через день. По итогам той проблемы я подготовил упрощенный пример для вас, чтобы вы поняли приемы, которые я применял.

В этом примере автоматизируется производственная компания, которая что-то производит. Есть номенклатура, у номенклатуры соответственно есть спецификации производства.

 

 

И у нас есть документ План производства.

  • На первой закладке мы заполняем ту продукцию, которую будем производить.

  • А на второй закладке эту продукцию разузловываем до материалов.

При этом продукция производится из материалов с использованием полуфабрикатов – то есть у нас появляется рекурсивное разузлование.

 

 

Что такое разузлование? Наша продукция, например, делается из древесины, стекла и еще чего-то. Это могут быть как материалы, так и полуфабрикаты. Если мы встречаем полуфабрикат, мы его разузловываем по его спецификации в элементы более низкого уровня. У нас получается дерево, и такие разузлования как правило выполняются рекурсивными алгоритмами.

Разузлование по первому варианту у нас завершилось за 20 секунд.

Давайте посмотрим, как это выглядит в конфигураторе.

 

 

Вот процедура, которая выполняет разузлование по первому варианту. Мы просто перебираем строки плана производства, и по каждой строке получаем подчиненные материалы.

 

 

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

Очевидно, что мы имеем запрос в цикле. Думаю, что любой специалист по 1С знает, что запрос в цикле – это плохо. Так делать нельзя.

 

 

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

Индексы – классная штука, они очень сильно ускоряют поиск по таблице значений. Мой любимый вопрос на собеседовании: «Что такое индексы в таблице значений?» Нормально на этот вопрос мне отвечают только 20%.

 

 

Когда мы предварительно собираем данные в таблицу по второму варианту, система завершает разузлование всего за 4 секунды – простым приемом мы оптимизировали код в 5 раз.

Если индексы убрать, то разузлование займет 19 секунд, потому что я нагенерировал в справочниках очень много данных, чтобы продемонстрировать вам производительность.

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

 

 

Чаще всего мы имеем дело с типовыми решениями, которые выглядят как-то так: «РазузловатьПродукцию» –> «РазузловатьПродукциюТут» –> «РазузловатьПродукциюТам» –> «РазузловатьПродукциюГдеТоЕще» и т.д.

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

Я сам разрабатывал в 1С и знаю, что обычно такая ситуация чем-то обусловлена. Например, в ERP вполне логичный, нормальный код. Но в результате того, что УТ вырезается из ERP, какие-то куски удаляются, и кажется, что там спагетти-код. Но специально так никто не делает.

 

 

Мы добрались до нашей глубоко закопанной процедуры, где и был наш запрос в цикле. Оптимизировать его сложно. Какое решение здесь есть?

Для хранения закэшированного результата запроса можно применять повторно используемые модули.

 

 

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

 

 

Причем сам повторно используемый модуль у меня ничего не делает – он просто создает пустую таблицу.

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

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

При рекурсивном выполнении в первый раз код заполнения кэша выполняется, а во второй раз уже не выполняется.

Такой кэш удобно делать, он получается очень гибким.

 

 

Выводы:

  • Кэширование существенно ускоряет работу – простым действием мы ускорили работу в пять раз.

  • Когда мы получаем такие спагетти-процедуры, в них удобно врезаться с помощью повторно используемых модулей. С их использованием алгоритм разузлования занял 4,6 секунд (изначально было 20 секунд).

 

Многопоточная обработка

 

 

Многопоточная обработка – это классный инструмент:

  • Она позволяет распараллелить работу, выполнить больший объем работ за единицу времени.

  • При параллельном выполнении задач аппаратные ресурсы используются более эффективно.

Но есть много сложностей и подводных камней, о которые можно споткнуться.

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

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

 

 

Основная сложность при организации многопоточной обработки – синхронизация потоков.

Первый вариант – в лоб. Получаем все данные для обработки, распределяем их по потокам, и каждый поток обрабатывает назначенную порцию.

При этом есть сложности:

  • Первая сложность – большое потребление оперативной памяти, потому что при получении всех данных для обработки мы вынуждены их держать в оперативной памяти.

  • Вторая сложность – конструкция будет довольно сложная. Ее придется обкладывать логами или механизмами мониторинга. А если поток упадет – его надо перезапускать.

 

 

Со временем я для себя принял такую концепцию, что распределять по потокам динамически не надо. Лучше:

  • Выбрать в базе данных объект, на который навесить номер обрабатываемого потока. Например, если у вас несколько складов, и вы пакетно обрабатываете документы реализации – можно номер потока “повесить” на этот самый склад. Или же номер потока можно назначить на клиента.

  • Дальше в каждом потоке вы уже считываете объекты гарантировано по этому потоку. Причем считывать вы их можете порционно.

  • Если что-то упадет, вы гарантировано знаете, что обработалось, а что – нет. За счет того, что вы увидите: есть какие-то объекты к обработке по определенному потоку.

 

 

Как это выглядит технически. У нас получается управляющий поток и набор потоков, которые обрабатывают данные:

  • Управляющий поток выбирает различные номера потоков из тех объектов, которые планируется обработать.

  • И дальше запускает столько потоков, сколько объектов нужно обработать – в каждом потоке выбираются только объекты для обработки в рамках этого потока.

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

Небольшой пример, как это может выглядеть в базе данных.

 

 

У нас есть документы «Реализация», которые нужно классифицировать по складам.

  • Первым этапом мы выбираем различные номера потоков из складов в «Реализациях»,

  • Дальше мы запускаем столько потоков, сколько у нас номеров потоков к выполнению.

  • И ждем их завершения.

 

 

Внутри процедуры «ВыполнитьКлассификацию(НомерПотока)» у нас отбираются реализации строго по этому номеру потока. И дальше обязательно накладываем блокировку.

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

 

 

Время обработки 6 тыс. документов для этого примера заняло:

  • в одном потоке – 46 секунд;

  • 3 потока – 16 секунд;

  • 5 потоков – 14 секунд;

  • 10 потоков – 11 секунд;

  • 15 потоков – 10 секунд.

Но если продолжить добавлять потоки, то время ползет вверх. Это удивительно, но это так.

 

 

И, например, я у себя добился воспроизведения ошибки. Если на моем домашнем сервере запустить примерно 40-50 потоков – то ровно через 4-5 часов он выдает мне вот такую ошибку.

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

У нашего клиента сервер себя интересно вел. Мы его загрузили потоками почти под 100%. Понятно, что сервер надежнее домашних компьютеров и сервер успешно обрабатывал данные в фоновых задания, пускал пользователей в базу, но дальше интерфейс не шевелился, ничего не происходило.

 

 

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

 

 

Вывод: многопоточная обработка – очень интересная штука, но к ней надо подходить аккуратно. При бесконечном увеличении потоков вы существенного выигрыша не получите, а можете налететь на странные ошибки.

 

Система компоновки данных

 

Давайте теперь немного поговорим про СКД. Очень интересная вещь, очень люблю на собеседованиях задавать вопросы по ней. Но, как показывает практика, не все ее любят так, как я.

 

 

Главная задача: я решил распределить разработчиков по классификации АBC в зависимости от того, насколько сильно они косячат.

  • класс A – мало косячит;

  • В – средне косячит;

  • С – косячит больше всех.

Классификация АВС основана на правиле Парето, которая формулируется как «20% клиентов приносит 80% продаж».

 

 

Первым решением – в ресурсе схемы компоновки данных написали собственную функцию, которая выполняла классификацию.

 

 

Но, как оказалось, в СКД есть встроенная функция, классификация которой работает не хуже и выдает аналогичный результат.

 

 

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

  • Можно реализовать запросом соединения меньше либо равно, потом сделать максимум – но это работает это не очень быстро.

  • Можно сделать запрос в цикле – кодом в модуле.

  • А третий вариант – это сделать запрос в цикле средствами СКД.

 

 

Для этого в схеме компоновки данных нужно сделать два набора.

  • Первый набор выводит те месяца, по которым нужно подобрать курсы валют.

  • Второй набор – делает запрос к срезу последних курсов валют на дату, которая указана в параметре.

При этом передачу параметра мы делаем через связи таблиц, и СКД автоматически начинает работать так, как будто мы выполняем запрос в цикле.

Тут еще есть интересная возможность. Видите галку «Список параметров»? Если эту галку поставить, система начнет для «Выражения источник» формировать в пакеты по тысяче штук и помещать их в параметр. Выполнять запрос в цикле, но на каждую тысячу штук. Это очень интересная возможность, мой любимый вопрос на собеседовании.

 

 

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

Например, из недавнего опыта был интересный кейс – надо было сделать по данным прогноз линейным и экспоненциальным трендом. В принципе, для программиста несложно. Кто знает – это обычная регрессия.

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

 

Интеграция система-система

 

Следующий кейс – система для обработки большого объема данных.Об этом проекте я подробно рассказывал в докладе на Infostart Event 2019. Сегодня я освещу некоторые технические аспекты этой системы.

 

 

Вы знаете, что чтобы обмениваться данными между 4 системами нам нужно настроить 6 интеграций – это очень много. Поэтому когда у нас встала такая задача, мы пошли по другому пути – решили поставить систему класса «Шина данных».

 

 

Шина данных или ESB-система выполняет роль коннектора, единого окна для всех систем. Например, когда CRM хочет запросить какие-то данные у АБС (автоматизированной банковской системы), то:

  • CRM вводит сообщения в шину данных;

  • шина данных маршрутизирует запрос в АБС;

  • дожидается ответа от АБС;

  • и возвращает его в CRM.

 

 

Шину данных мы реализовали собственную, на 1С. Для исключения проблем с производительностью мы обложили ее RabbitMQ и кэшем на Redis.

Идея простая – на слайде показан пример запроса с клиентского сайта на расчет графика платежей:

  • клиентский сайт запрашивает данные;

  • BPM-система проверяет в Redis-сервере наличие готового графика;

  • возвращает его, если он там есть;

  • если его нет – запрашивает его у системы АБС.

В чем сложность? Все сообщения логировались в регистре сведений, и буквально через несколько дней список этого регистра сведений уже не мог даже открыться, потому что данных было очень много – там на момент запуска летало от 400 до 2000 сообщений в секунду.

Потому что через шину работали и мобильные приложения, и сайт, и CRM, и внешний CRM – это было ядро интеграции. Данных было много, поэтому:

  • скорость обработки сообщений деградировала;

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

 

 

Для решения мы сделали:

  • два одинаковых регистра сведений – один архивный, один основной;

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

 

 

На слайде показан текст этой процедуры.

Поскольку блокировки мы накладываем на некоторые минимальные размеры данных, потери производительности мы даже не заметили.

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

 

 

На этом проекте проявилась еще одна интересная особенность:

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

Сначала я использовал для этого запрос с итогами по формуле МАКСИМУМ(Период), но это занимало большое время.

Я попробовал поставить для регистра флаг «Разрешить итоги» и использовать «Срез последних» без даты. Ускорилось классно, запрос стал работать быстро, но запись в регистр просела больше, чем выигрыш от чтения.

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

Вывод: с виртуальными таблицами нужно аккуратно. Подбирайте для них оптимальные варианты использования, когда нужно, чтобы обязательно итоговые таблицы были задействованы. Тем не менее, варианты с реальными таблицами тоже нужно проверять на всякий случай.

 

 

Когда мы столкнулись с проблемой производительности, у нас первая мысль была – апгрейдить сервер, поиграть с индексами. Но простое разделение на основные и архивные данные здорово повысило скорость работы и помогло завершить проект.

 

Использование дихотомических алгоритмов для решения типовых задач

 

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

 

 

Как и на слайде, я в институте с высшей математикой не дружил. Высшую математику я изучал впоследствии, после института, и об этом не пожалел.

Есть задачи, которые называются задачами оптимизации – для них еще встречается термин NP-полные задачи.

Задача с недавнего проекта – балансировка плана. У нас есть:

  • объем материалов, который закупщики обещают закупить;

  • объем продукции, который продажники обещают продать;

  • есть пропускная способность заводов;

  • и есть ограничения – сколько сырья должно оставаться на складах в тот или иной период времени.

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

 

 

Решаются такие задачи разными способами.

  • Первый и самый точный, но долгий – полный перебор. На более-менее серьезных объемах это не сработает, это невозможно.

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

  • На 1С, по моему опыту, здорово работают дихотомические алгоритмы. Они очень простые в программировании. На том примере с балансировкой планов, который я приводил, мы предварительно просчитывали всю модель в Excel, проверяли через мастер решений, который позволяет найти те или иные оптимальные параметры. И потом сравнивали с тем, как 1С считала дихотомическим алгоритмом – разница получалась в несколько килограммов. Было принято решение, что алгоритм можно запускать в продакшн, и он вполне подходит.

 

 

Что такое такое дихотомический алгоритм?

  • У нас есть некоторая функция, желательно, чтобы она была монотонно возрастающей/убывающей. Мы знаем ее область определения, причем область определения мы можем придумать сами.

  • Делим эту область определения пополам, берем на каждом из участков симметричные точки, определяем значения функции на этих точках и находим среди этих значений максимальное.

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

Самый смешной случай применения алгоритма в моей практике – расчет размеров торта. Это когда клиент говорит: «Я хочу двухэтажный торт весом 5 килограмм, первый этаж – йогуртового вкуса, второй – сливочного» и нужно просчитать размер заготовок для каждого этажа, чтобы кондитеры брали заготовки нужного размера, не задумываясь.

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

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

 

Выводы

 

 

Общие выводы по презентации:

  • Призываю вас изучать различные алгоритмы решения нетиповых задач – это интересно и повышает вашу ценность как специалиста.

  • Работайте с готовыми паттернами, и вам не придется изобретать велосипеды.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Ekaterinburg.Online.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Infostart Toolkit: Инструменты разработчика 1С 8.3 на управляемых формах

Инструментарий разработчика Роли и права Запросы СКД Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

10000 руб.

02.09.2020    122304    673    389    

716

СКД на JavaScript в 1С

СКД WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Долгое время поддерживаю web-портал, в котором появилась необходимость создавать отчеты. Просмотрев различные фреймворки на js, я решил сделать свое решение, которое позволяло бы быстро разрабатывать и добавлять новые отчеты на web-портал.

2 стартмани

11.12.2023    8169    20    John_d    25    

123

Правила работы с транзакциями 1С

Рефакторинг и качество кода Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Список правил при работе с транзакциями из BSL Language Server и SonarQube 1C (BSL) Plugin. Переработка и осмысление материала.

01.12.2022    12936    kuzyara    47    

95

Хитрости СКД. Часть 3

СКД Универсальные функции Платформа 1С v8.3 Система компоновки данных Конфигурации 1cv8 Бесплатно (free)

Столкнулся с тем, что мне приходится писать гору отчетов. Во многих приходится использовать повторяющиеся приемы. Решил написать шпаргалку, которая, надеюсь пригодится не только мне. В этой статье: Объединение ячеек в отчете только на определенном уровне иерархии, Постобработка итогов в табличном документе, Скрытие колонок в зависимости от количества месяцев в периоде.

28.05.2022    9299    milkers    11    

94

Мастер-класс SonarQube. В омут с головой

Рефакторинг и качество кода Бесплатно (free)

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

19.05.2022    21052    nixel    112    

159

Шаблон отчета на СКД (обычные формы)

СКД Платформа 1С v8.3 Система компоновки данных Конфигурации 1cv8 Абонемент ($m)

Улучшенный шаблон отчёта СКД, реализованный на обычных формах. Лаконичный и функциональный, весь необходимый минимум для управления отчётом вынесен на форму отчёта, что избавляет рядовых пользователей от необходимости лезть внутрь настроек отчёта. Форма сделана гибкой и позволяет легко себя адаптировать под Ваши потребности. Ряд элементов формы сделан сворачиваемыми и растягиваемыми.

2 стартмани

14.02.2022    8312    34    Eugen-S    5    

13

Реализация отборов на форме с помощью СКД

СКД Платформа 1С v8.3 Система компоновки данных Конфигурации 1cv8 Бесплатно (free)

В статье описана практическая методика использования системы компоновки данных (СКД) для реализации отборов на любых формах конфигурации.

28.12.2021    23904    quazare    10    

145
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. aspirator23 339 08.04.21 10:49 Сейчас в теме
Как то столкнулся, что больше чем 49 фоновых заданий не создается. Точно уже не помню на 49 падает или 49 это последнее. Так что "...запустить примерно 40-50 потоков..." это похоже оттуда. Причем ровно 49. Не 50. Видимо какой то изувер писал. :)
4. Jimbo 9 09.04.21 12:32 Сейчас в теме
(1) не помню, до скольки фоновых заданий доходило, писал отчет на СКД - запрос - выдавал таблицу значений, далее эти таблицы собирались в другую итоговую - набор объект, замеры времени показали что оптимально 10 потоков. Потоки делились по периодам неперескающимся, организациям, подразделениям и т.д.
2. user1299034 08.04.21 20:10 Сейчас в теме
Из ИТС: "В частности, следует иметь в виду, что кэш не хранит данные вечно. Закэшированное значение будет удалено из кэша через 20 минут после вычисления или через 6 минут после последнего использования (в зависимости от того, что наступит раньше. Кроме этого значение будет удалено при нехватке оперативной памяти в рабочем процессе сервера, при перезапуске рабочего процесса и при переключении клиента на другой рабочий процесс. "
Наверное нужно проверять еще, не очистился ли кэш? Или возвращать не "Новый ТаблицаЗначений", а то, что возвращается при первом обращении.
А в целом побольше бы такого рода докладов, как у вас, которые можно применять в широкой области.
3. SergeyN 1074 08.04.21 23:38 Сейчас в теме
(2) Срок жизни кэша несомненно нужно соотносить со временем выполнения алгоритмов. В моем примере при возврате "Новый ТаблицаЗначений" - через 20 минут таблица будет заполнена повторно. Т.е падения алгоритма не произойдет, просто кэш обновится.
5. Yashazz 4709 11.04.21 17:19 Сейчас в теме
Вот не то чтоб переход на личности, но всё, связанное с указанной ВайсЭдвайс, производит устойчивое ощущение криворукой пионэрии, на коленке пилящей костыльные времянки. Теория-то красивая, слайды впечатляющие, доклад такой весь солидный выходит... Хочется спросить: ребята, а ваши сотрудники на практике хоть сотую часть всего этого применять могут, или им принципиально низя?
Сколько сталкивался - методисты аховые (сперва не продумывают задачу даже на шаг вперёд, потом, когда грабли случаются, валят всё на разработчиков), админы тоже (подымают сетевое хранилище, обрывающее связь через два раза на третий, и обвиняют потом разработчиков в неумении работать с хранилищем), а уж что ваши "программисты" делают, пусть лучше моя жена расскажет, а то у меня слишком нецензурно получится.
Это параллельные вселенные такие, да? В одном благостные солидные дяди делают доклады, наращивают репутацию и охмуряют клиентуру, а в другом ж*порукие стажёры да субподрядчики кропают лютую хрень? Так, да?

Я к чему? Я к тому, что "приемами разработки, которые помогут избежать потенциальных проблем при реализации сложных проектов" являются в первую и главную очередь владение основами и азами. И просто грамотной работой. А то, знаете, трудно назвать грамотным создание своего реквизита в охрененных размеров типовом справочнике, притом, что достаточно было сделать дополнительное свойство штатными средствами БСП.
8. sulfur17 59 12.04.21 11:14 Сейчас в теме
(5)
в охрененных размеров типовом справочнике

справочник складов охрененного размера?
11. Yashazz 4709 12.04.21 16:36 Сейчас в теме
(8) У жены уточню, это она месяц назад на подобный креатив натолкнулась. То ли в ЕРП, то ли в ЗУП, но точно не склады.
12. SergeyN 1074 14.04.21 15:39 Сейчас в теме
(5) Яков, я разобрался в ситуации про которую вы пишите. Руководитель группы компаний Иван Тягунов уже давал вам развернутый комментарий по этому вопросу:

https://forum.infostart.ru/forum6/topic192819/#message2009968

Цитирую:
"Но я уже прояснил ситуацию - мы были в этом проекте в рамках того плана и ТЗ, которые нам были заданы упомянутым генподрядчиком, да и начали мы там не с "0", а доделывали за другими товарищами. Поэтому, естественно, и цейтнот и бардак там присутствовали. Но в целом цели проекта были в результате достигнуты."
13. Yashazz 4709 14.04.21 17:22 Сейчас в теме
(12) к сожалению, это не единственный случай; и я, и моя жена сталкиваемся с подобными "эффектами" и в настоящее время.
6. triviumfan 93 11.04.21 22:23 Сейчас в теме
""Процессинг обработки", - а ю сириэз?:)
SergeyN; AlekseiAdamov; nbeliaev; +3 Ответить
7. user1140274 12.04.21 09:53 Сейчас в теме
Сергей, напишите статью про 1С:Аналитику, архитектуру решения, перспективы её использования и сравнения с Qlik View, Power BI и опыт её внедрения, если был
10. SergeyN 1074 12.04.21 15:40 Сейчас в теме
(7) Про 1С:Аналитику докладывала наш разработчик Ирина Богданова на митапе по BI системам
https://infostart.ru/courses/1329967/

По поводу сравнения 1С:Аналитики и других систем - интересная идея, я подумаю над реализацией.
9. sulfur17 59 12.04.21 11:15 Сейчас в теме
Очень хорошая статья! Идеи взял на вооружение.
Оставьте свое сообщение