От экспертов «1С-Рарус»: Настраиваем «Закрытие месяца» в 1С:ERP с 500 000 первичных документов ежемесячно. Часть III

Цикл статей об оптимизации «Закрытия месяца» в 1С:ERP

Вашему вниманию предлагается третья часть из цикла статей по оптимизации расчета операции «Закрытие месяца» в 1С:ERP.

Давайте для начала вспомним о чем мы говорили в двух предыдущих частях:

• В первой части мы подробно рассмотрели процесс отладки расчета себестоимости и подкрепили практическими кейсами полученные знания. В том числе, снабдив читателя приемами отладки в высоконагруженных продуктивных системах.
  Выявляем причины долгого «Закрытия месяца» в 1С:ERP и ускоряем выполнение операции. Часть I.
• Во второй части мы продолжили применять наши знания на практических примерах, в том числе поговорив о случае, когда операция и вовсе не доходит до своего завершения.
  Расследование и оптимизация расчета операции «Закрытие месяца» в 1С:ERP. Часть II.

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

1С:ERP для производства муки и хлебобулочных изделий

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

Особенностью учета данного предприятия является объем первичных документов. В базу данных ежемесячно вносится порядка 500 000 документов, из них 210 000 – 240 000 документов реализации. Режим работы предприятия 24*7, доступность информационной системы 24*7, работа пользователей в системе ведется непрерывно.

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

Какие сервера нужны для 1С с 500 000 первичных документов в месяц

Сервер СУБД

• Microsoft SQL Server Enterprise: Core-based Licensing (64-bit) 15.0.4153.1.
• Оперативная память: 169 ГБ.
• Процессор: 3.1 ГГц, 24 ядра.

1С

• Платформа: 8.3.17.
• ERP: 2.5.5.82.

Серверы кластера 1С

• Оперативная память: 169 ГБ.
• Процессор: 3.1 ГГц, 24 ядра.
• 3 рабочих сервера, 1 центральный.
  Сервера имеют одинаковую аппаратную составляющую:
  • Оперативная память: 48 ГБ.
  • Процессор: 3.1 ГГц, 24 ядра.

Сервер СУБД и сервера приложения развернуты в облаке. Прирост базы данных за год 800 ГБ.

Выполняем требование «Стабильное закрытие месяца»

Отметим, что 1 января 2021 года система вышла в опытную эксплуатацию, был выполнен запуск системы «с нуля» и проблемы решались по мере их появления.

Ошибка при расчете себестоимости

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

При запуске процедуры закрытия месяца первоначально выполнялся этап «Актуализация движений взаиморасчетов», этап завершался штатно и мы переходили к расчету себестоимости, который в определенный момент времени завершался без объяснения причин, единственное описание ошибки, которую удалось получить, это была ошибка в консоли фоновых заданий «Аварийно завершился процесс фонового задания». Протокол расчета себестоимости мы тоже не получали. В версии 2.5.5.82 еще не было режима отладки расчета, который мы разбирали в первой части нашего повествования Выявляем причины долгого «Закрытия месяца» в 1С:ERP и ускоряем выполнение операции. Часть I. Забегая вперед скажем, что длительности этапа расчета себестоимости, которую мы получили после первого удачного расчета составила 22 часа 31 минута. Такая длительность не позволяла определить проблему путем прохода расчета в отладке, падение задания расчета происходило в непредсказуемый момент времени.

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

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

После анализа журнала регистрации были сделаны выводы:

1. до момента падения, расчет выполнялся штатно;
2. падения происходило на разных этапах расчета себестоимости.

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

Собираем данные в технологический журнал

На серверах приложения был настроен технологический журнал. А так же был настроен сбор данных Performance Monitor.

При анализе Performance Monitor мы увидели следующую картину:

В момент падения расчета себестоимости на сервере приложения доступная оперативная память имела минимальные значения.

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

Перезапуск рабочих процессов

Соединив вместе информацию полученную из Performance Monitor и технологического журнала мы пришли к выводу, что происходит завершение рабочего процесса сервером 1С:Предприятия вследствие превышения допустимого объема памяти.

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

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

Изолируем расчет себестоимости на отдельном сервере

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

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

Определившись с механизмом, мы пошли творить:

1. Был выбран сервер 1С:Предприятия из состава кластера, который планировалось выделить для целей расчета себестоимости.
2. Были выполнены настройки требований назначений функциональности.

На первом этапе были сделаны следующие настройки:

Требованием под номером 18 мы указали, что использование сервера недоступно, кроме требований 12, 13 и 14. Для корректной работы требований необходимо правильно выстраивать последовательность требований, если мы укажем требование «Для всех не назначать» самым первым, то дальнейшие требования будут проигнорированы.

Поскольку расчет себестоимости выполняется в фоновом задании была использована конструкция BackgroundJob.CommonModule.<Имя модуля>.<Имя метода>, которая используется для указания конкретного фонового задания, запущенного из встроенного языка.

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

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

После выполненных настроек мы смогли выйти на «более-менее» стабильный расчет себестоимости.

Рационализируем использование отдельного сервера под расчет себестоимости

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

Для более рационального использования ресурсов сервера было принято решение перенести часть выполняемых роботов на данный сервер. Мы определили список фоновых заданий с предсказуемым потреблением ресурсов. Для определения списка мы проанализировали исполняемый код фоновых заданий. Были выбраны задания, в которых нет объемных выборок данных, произвольных периодов, прогнозируемо исполняемый код. Далее мы постепенно выносили их на сервер к расчету себестоимости, отслеживая потребление памяти. После окончания формирования списка заданий настройки требований назначений приобрели следующий вид:

Из важных моментов, которые мы подчеркнули в процессе эксплуатации хочется отметить:

1. Требование под номером 1. Данное требование запрещает формирование любых отчетов на данном сервере, это было сделано вследствие того, что отчет является непредсказуемым по потребляемым ресурсам.
2. Требование под номером 16. Конструкция BackgroundJob.CommonModule должна «в теории» отправлять на данный сервер все фоновые задания, запущенные из кода, однако, как мы выяснили, в нашем случае данная конструкция не работает.
3. Требование под номером 4. Данное требование запрещает отправлять на данный сервер поиск в списке. Поиск в списке должен выполняться на том же сервере, на котором работает пользователь, иначе мы получим сильную задержку, при передаче данных и поиск будет тормозить.
4. Не забываем настроить на других серверах в кластере требования назначения функциональности, запрещающие выполнения заданий, которые мы выделили на отдельный сервер.

Так образом мы одержали победу в сражении, но не в войне…

Повторное появление аварийного завершения расчета себестоимости после 2-х месяцев эксплуатации

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

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

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

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

Решение было найдено после анализа списка рабочих процессов, а конкретно параметра «Время запуска». Было обнаружено, что рабочие процессы с разных серверов имеют одинаковое время запуска, это побудило нас проверить, не является ли данная картина результатом настроек кластера.

И такая настройка была найдена. Ей оказался интервал перезапуска рабочих процессов, было установлено значение 86400 секунд, что соответствует 24 часам. Интервал перезапуска — отвечает за частоту перезапуска рабочих процессов кластера. Существует распространенная практика, установки интервала перезапуска рабочих процессов, это помогает в борьбе с повышенным расходом памяти на сервере 1С:Предприятия. В нашем случае такой проблемы не наблюдалось, однако привычка настраивать перезапуск рабочих процессов уже сформировалась.

Данный метод борьбы за общую производительности в целом неплох и часто помогает, однако он имеет очень существенный минус. Минусом данного метода является то, что при перезапуске рабочего процесса в новый rphost переезжает только клиентское соединение. Серверные вызовы и фоновые задания не умеют переезжать и завершаются вместе со старым процессом через время указанное в настройке «Проблемные процессы завершать через», в нашем случае 300 секунд.

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

Итак мы одержали очередную победу в войне за стабильность…

Ошибки конфликтов блокировок и замедление работы ERP у пользователей

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

Поиск причин начали с консоли кластера и колонки «Захвачено СУБД».

Проверяем время захвата соединений с СУБД

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

В итоге анализа консоли кластера было обнаружено, что в момент возникновения проблем с производительностью и массовых блокировок регламентное задание «Отражение документов в регламентированном учете» начинало захватывать соединение с базой данных, признаком этого были значения в колонке «Захвачено СУБД» в районе 3000–4000 секунд. Принудительное завершение задания восстанавливало работоспособность базы, что убедило нас в необходимости присмотреться поближе к отражению в регламентированном учете.

Разбираем задание «Отражения документов в регламентированном учете»

Необходимо было разобрать алгоритм работы отражения в регламентированном учете.

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

Задание отражения начинается с процедуры ОтразитьВсеРегламент, взглянув на нее внимательно мы обнаружили в ней вызов 3-х функций:

1. УчетНДСУП.ВыполнитьФормированиеДвиженийПоНДС(КонецМесяца(ТекущаяДата)).
2. РеглУчетПроведениеСервер.ОбновитьДанныеЗависимыхРегистров().
3. РеглУчетПроведениеСервер.ОтразитьВсе(КонецДня(ТекущаяДата)).

Для более точной идентификации проблемы, мы разделили описанные выше процедуры на 3 отдельных задания и начали наблюдать. В результате, используя консоль кластера, мы выяснили, что соединение с базой данных держит функция РеглУчетПроведениеСервер.ОтразитьВсе(КонецДня(ТекущаяДата)).

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

То есть создаваемый в начале процедуры менеджер временных таблиц существует все время выполнения отражения и учитывая, что временные таблицы будут существовать в памяти компьютера до закрытия менеджера временных таблиц (автоматически или принудительно методом Закрыть()) или до исполнения запроса, связанного с этим менеджером, уничтожающего временную таблицу с помощью конструкции УНИЧТОЖИТЬ, мы решили, что именно данный менеджер временных таблиц удерживает соединение с СУБД.

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

В ходе отладки и анализа кода мы проследили путь созданного менеджера временных таблиц до процедуры ОтразитьДокументыПакетно. В данной процедуре выполняется выборка 1000 документов из очереди к отражению и передача их в процедуру ВыполнитьОтражение. Мы приняли решение закрывать менежер ВТ и пересоздавать его заново для каждой порции документов.

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

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

Ускоряем расчет «Закрытия месяца» в ERP

Когда мы смогли добиться стабильного расчета на первый план вышла проблема длительности.

В нашем случае закрытие могло выполняться от 12 до 30, а в последствии и 40 часов.

В первую очередь мы определили длительность основных этапов закрытия:

1. Актуализация движений документов по данным взаиморасчетов.
   Время выполнения порядка 3–4 часов.
2. Расчет себестоимости.
   Время выполнения от 8 до 30 часов.
3. Отражение документов в регламентированном учете.
   Время выполнения до 6 часов.

Как ускорить «Расчет себестоимости»?

Работу мы начали с этапа «Расчет себестоимости». Такое решение было принято исходя из опыта борьбы за стабильности системы, чем дольше выполняется операция, тем больше шансов получить исключительную ситуацию.

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

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

Первоначальный расчет длительностью: 19 ч. 55 мин. 53,941 сек.

Повторный расчет длительностью: 9 ч. 28 мин. 16,163 сек.

Как можно заметить основная разница в этапе №88. Партионный учет: ЗаписатьСформированныеДвижения. При первичном расчете месяца мы фиксируем движения по всем документам, введенным за месяц, а при повторных расчетах только для измененных с момента предыдущего расчета.

Что делать с «Заполнением партий»?

Наше расследование мы начали с этапа ЗаполнениеПартийВРегистреСебестоимостьТоваров.

В результате анализа было выявлено, что в ходе построения цепочек для расчета партий получатся 2 таблицы, каждая по 277 млн. записей, которые обрабатываются не очень быстро. Результаты анализа вместе с протоколом были переданы на линию консультации фирмы «1С». После анализа наших данных была признана проблема и зафиксирована ошибка. Проблемой в нашем случае являлось большое количество корректировок реализаций, которые создавали излишние связи.

По причине наличия планов на обновление системы до версии 2.5.7 от работ по самостоятельной переделке заполнения партий было решено отказаться и ждать исправления от фирмы «1С», в расчете получить их в целевой версии при обновлении.

Оптимизируем «Запись сформированных движений»

Отказавшись от переписывания расчета партий мы сфокусировались на причинах медленной записи движений.

Для возврата к оптимизации записи движений появился хороший повод. В сентябре 2021 года первоначальный расчет длился: 30 ч. 53 мин. 12,091 сек., запись движений при этом заняла почти половину данного времени.

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

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

Проверяем скорость работы дисковой подсистемы

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

Выполнив несложный скрипт на сервере СУБД.

Мы получили среднее время чтения файла базы данных порядка 45, а записи 20 миллисекунд.

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

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

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

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

Было назначено расследование, в результате которого, мы выяснили, что на тестовом стенде на сервере СУБД был включен параметр параллелизма SQL (параметр max degree of parallelism) в значении 12, на рабочем сервере СУДБ данный параметр установлен в значение 1.

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

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

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

Далее была предпринята попытка установки параллелизма на продуктивном сервере СУБД, которая не привела к успеху, задержки на ожидании параллелизма перекрывали эффект от его использования. От этой идеи отказались.

Была обнаружена следующая картина:

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

На основании всех полученных данных, мы пришли к выводу, что серверу СУБД не хватает процессорного ресурса.

Были выполнены следующие изменения:

1. С сервера СУБД с самой «тяжелой» базой были вынесены все остальные базы на отдельный сервер СУБД.
2. Количество процессоров увеличено с 24 до 32.
3. Оперативная память увеличена с 169 до 262 ГБ.

В результате выполненных изменений производительность базы улучшилась. Скрипт выполнения ночного регламента был изменен, для операции перестроение индексов и обновление статистики был использован параметр max degree of parallelism равный 0, передаваемый непосредственно в исполняемую функцию. Значение параметра max degree of parallelism 0 означает, что SQL сервер сам выбирает значение данного параметра для выполнения функции. В результат ночное обслуживание базы стало выполняться от 2-х до 3,5 часов.

Показатели работы дисковой подсистемы так же улучшились.

Распараллеливаем «Запись сформированных движений» в 1С:ERP

Поработав над сервером СУБД настала очередь и ERP. Имея хороший запас производительности сервера было принято решение распараллеливать запись движений насколько это возможно. Были установлены следующие настройки операций закрытия месяца.

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

Вместе с тем, для избежания потери данных в случае конфликта блокировок была выполнена доработка процедуры ЗаписатьНаборЗаписей модуля РасчетСебестоимостиПрикладныеАлгоритмы. Был реализован бесконечный цикл записи с паузой в 1 минуту, в случае получения ошибки конфликта блокировок.

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

В итоге проделанной работы при полном расчете декабря мы получили длительность этапа записи движений в: 1 ч. 59 мин. 25,485 сек., общее время расчета себестоимости декабря 16 часов.

Планы по дальнейшей оптимизации «Закрытия месяца» в 1C:ERP

Мы все еще продолжаем работы по ускорению закрытия месяца. В планах на ближайшее будущее оптимизация функции ВернутьДокументыКОтражению, по методу, описанному во второй части нашего цикла (От экспертов «1С-Рарус»: Расследование и оптимизация расчета операции «Закрытие месяца» в 1С:ERP. Часть II).

Это позволит нам получить ускорение сразу в 2-х местах:

1. Этап расчета себестоимости ЗарегистрироватьКОтражениюВРегламентированномУчете.
2. Операция «Актуализация движений документов по данным взаиморасчетов», поскольку функция ВернутьДокументыКОтражению вызывается по окончании этой операции и занимает продолжительное количество времени.

Также в планах уменьшить значение параметра закрытия «Максимальное количество движений, записываемое одним фоновым заданием» поскольку он напрямую влияет на количество заданий записи движений. При установленном значении по умолчанию 100000 мы имеем 31 задание для записи регистров «Себестоимости» и «Выручки и себестоимости» и всего 5 для записи регистра «Прочие активы и пассивы».

Итоги третьей части цикла экспертных статей про оптимизацию «Закрытия месяца»

Время подводить итоги третьей части нашего путешествия по лабиринту ERP.

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

Во-вторых, показали насколько важным и мощным инструментом является настройка сервера 1С:Предприятие. Как одни настройки помогают решать проблемы, а другие создавать их.

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

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

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