Оптимизация времени формирования портала

Формирование портала состоит из следующих этапов:

• Формирование структуры.
• Формирование отчетов.

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

Необходимо сформировать портал полностью один раз, чтобы рассчитать время формирования портала. Портал считается сформированным полностью, когда сформирована его структура и все отчеты, кроме отчетов по требованию (отчеты с приоритетом = 0). Показателем того, что все отчеты сформированы служит значение "100%" параметра "Сформировано" на вкладке "Консоль" вкладки "Администрирование" на портале (Рис.1).

Рисунок 1

Расчет времени формирования структуры, времени формирования отчетов и полного времени формирования портала можно провести после того, как портал сформировался полностью, по информации из файла C:\ProgramData\STU-Soft\www\Название_портала\log\time_struct.log¹⁾:

• Разность между моментами времени, указанными в строках "Start" и "Complete Struct" - это время формирования структуры.
• Разность между моментами времени, указанными в строке "Complete Struct" и последней по времени строке "Finish Report"- это время формирования отчетов.
• Разность между моментами времени, указанными в строке "Start" и последней по времени строке "Finish Report" - это время формирования портала.

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

Пример
Организация может решить, что доводить изменения до сотрудников необходимо один раз в неделю. Тогда полное время формирования портала желательно оптимизацией довести до 2,5 суток, чтобы портал, запущенный по расписанию, в пятницу в 20:00, был переформирован к 8:00 понедельника.

Если время формирования портала неприемлемо с точки зрения скорости доведения изменений до сотрудников, то рекомендуется:

1. Использовать опцию портала "Разрешать доступ к ранее сформированным отчетам". Это позволит устранить проблему неготовности части отчетов в момент обращения к ним пользователей. Отчеты будут открываться сразу, но, возможно, будут содержать устаревшую информацию (до того момента, как портал их переформирует в порядке общей очереди).
2. Провести оптимизацию времени формирования структуры портала и оптимизацию времени формирования отчетов портала (описание см. в одноименном разделе ниже).
3. Использовать распределенное формирование отчетов портала (см. описание в одноименном разделе ниже).
4. Использование для формирования портала реплик рабочей базы данных.
5. Задание приоритета формирования отчетов (описание см. в одноименном разделе ниже).

Для оптимизации необходимо:

1. Оптимальным образом задать права для пользователей, а именно там, где это возможно, права на справочники и классы выдавать через группы Active Directory (см. Права пользователей в портале).
2. Уменьшить количество выгружаемых на портал объектов, если это является возможным.
   Этого можно добиться:
   • Формируя портал по группе, в которую включить только нужный для портала набор объектов (регулируется с помощью параметра "Группа фильтра" в Окне свойств портала).
   • Изменив/уменьшив перечень классов, выводимых в портал (регулируется с помощью вкладок "Справочники портала" и "Дополнительные справочники" в Окне свойств портала).

Следует учитывать, что набор отчетов, предоставляемый в составе баз данных Business Studio по умолчанию, рассчитан на выдачу достаточно подробной информации за приемлемое время, что подходит для большинства клиентов. При необходимости вы можете доработать эти отчеты как в сторону усложнения, так и в сторону упрощения для получения оптимальной для вашей организации степени детализации отчетов и времени их формирования (подробнее об отчетах и их разработке см. в главе Руководства пользователя "Отчеты").

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

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

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

Служебные процессы с ролью "Формирование отчетов" формируют отчеты в фоновом режиме. Служебные процессы с ролью "Формирование отчетов по требованию" формируют отчеты только по запросам пользователей. Наличие таких служебных процессов позволяет быстрее получать отчеты, которые к моменту обращения к ним еще не были сформированы или у которых истекло время жизни.

Внимание! Оптимальное суммарное количество процессов с ролями "Формирование отчетов" и "Формирование отчетов по требованию" на одном сервере – 4. Это связано с ограничениями приложений Microsoft Office. Большее количество таких процессов может приводить к замедлению формирования отчетов.

Служебные процессы с ролью "Ввод показателей", кроме ввода показателей, нужны для авторизации пользователей и для распределения заданий при формировании отчетов²⁾. Они должны запускаться на основном сервере. Рекомендуется иметь 1 такой процесс на каждые 4-6 процессов с ролью "Формирование отчетов". Общее количество служебных процессов обычно равно количеству ядер процессора на сервере (за исключением основного сервера, где 2 ядра необходимо оставить для работы веб-сервера). Для мощных процессоров их может быть больше, количество подбирается экспериментально по показаниям счетчиков производительности за период формирования портала: средняя загрузка процессора не должна превышать 80%, а максимальный объем выделенной виртуальной памяти не должен превышать объема ОЗУ (то же касается и сервера с SQL Server).

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

Пример комбинации служебных процессов для 8-ядерных серверов

Пример расчета необходимого числа серверов формирования по данным о времени формирования портала.
Для упрощения будем считать, что на всех серверах (в том числе и на основном сервере портала) одинаковое число служебных процессов с ролью "Формирование отчетов" и одинаковое число служебных процессов с ролью "Формирование отчетов по требованию". Пусть имеется только один (основной) сервер, а общее время формирования портала составляет M = 2.5 суток = 60 часов. Требуется уменьшить его до T = 10 часов, чтобы портал можно было переформировывать ежедневно после рабочего дня, и он был готов к началу следующего рабочего дня. Тогда можно приближенно (без учета времени формирования структуры портала) вычислить количество серверов как M/T = 60/10 = 6. Т.е. помимо 1 основного сервера портала потребуется 5 вспомогательных серверов.

Если использование распределенного формирования не даёт требуемого результата (например, ожидали сокращение времени формирования в 5 раз, а сократилось только в 2), возможно, узким местом стала:

• Большая нагрузка на компоненты сервера (система хранения, сетевой адаптер, оперативная память). Для подтверждения этой гипотезы необходимо обратиться к системному администратору, для диагностики можно использовать информацию из следующей статьи: https://www.businessstudio.ru/wiki/faq/doku.php/ru/techsupport/sysmon
  Если гипотеза подтвердится, то решение проблемы находится в компетенции системного администратора.
• Большая нагрузка на базу данных MS SQL, по которой формируется портал. Для подтверждения этой гипотезы необходимо обратиться к системному администратору.
  Если гипотеза подтвердится, то для решения этой проблемы можно использовать репликацию баз данных и для каждого сервера портала использовать свою реплику основной базы данных.

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