• Режим просмотра и анализа. В этом режиме подключение ЦУП к исследуемой информационной базе не требуется. Эксперт на основе накопленной исторической информации анализирует производительность информационной базы и выявляет те участки конфигурации, которые являются источниками основных проблем производительности.

Анализ проблем производительности в контексте объектов метаданных

Любой измерительный прибор неизбежно вносит погрешности в наблюдаемую систему, и «Центр управления производительностью» не исключение. В режиме мониторинга с полной записью всех аналитических показателей (вплоть до текстов всех выполняемых в СУБД запросов) ЦУП создает в исследуемой информационной базе довольно существенную (на глаз – до 15 % от текущей) дополнительную нагрузку. Поэтому на «боевых» информационных базах, в которых уже наблюдаются проблемы с производительностью при работе большого числа пользователей, такой режим следует применять с осторожностью.

Генерация сценария для ТестЦентра

Какую информацию получает при помощи ЦУП эксперт для решения задач оптимизации работы информационной базы? Эту информацию можно разделить на три семантических уровня:

• общая информация о проблеме производительности («запрос является неоптимальным и вызывает ожидания на блокировках»);

• технологическая «привязка» проблемы к объектам конфигурации («выполнение проблемного запроса было инициировано в строке N модуля Х»);

• аналитическая оценка влияния проблемы на общую интегральную производительность системы («выявленный проблемный запрос на текущий момент является наиболее критичным и требует немедленной оптимизации»).

ЦУП не просто собирает информацию о проблемах, но и производит автоматическое ранжирование выявленных проблем. Аналитические алгоритмы ЦУП при определении веса проблемы учитывают время выполнения проблемных запросов, количество выполненных проблемных запросов за единицу времени, число порождаемых проблемным запросом ожиданий на блокировках, время ожидания и другие факторы. Например, в ходе анализа было выявлено два неоптимальных запроса, выполнение которых всегда вызывает взаимные блокировки. Среднее время выполнения первого запроса составляет 352 с, среднее время выполнения второго запроса – 1,85 с, но, чтобы понять, какой из них оказывает более сильное воздействие на общую производительность информационной базы, этих цифр явно недостаточно. Если первый запрос выполняется в среднем 0,08 раза в час, а второй запрос – 154 раза в час, то первой целью для оптимизации однозначно является именно второй запрос. Ранжирование проблем производительности позволяет эксперту сразу же перейти к поиску решений наиболее важных проблем, а ощутимый эффект от оптимизации будет достигнут уже на первом заходе.

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

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

Методики решения конкретных задач оптимизации конфигураций «1С: Предприятие 8» так же многочисленны, как и причины, порождающие проблемы производительности при многопользовательской работе. В наиболее простых случаях достаточно произвести регламентные работы на стороне СУБД или изменить режим индексирования тех или иных объектов прикладной конфигурации. В более сложных случаях требуется вносить в конфигурацию изменения – оптимизировать запросы, переписывать программный код, модифицировать структуру метаданных. Задачи оптимизации относятся к классу творческих, и универсальных рецептов их решения не существует. Но есть несколько вопросов, которые неизбежно возникают по ходу решения задач оптимизации, вне зависимости от конкретной ситуации и квалификации специалиста.

• Предложено несколько вариантов решения. Какие из них плохие, а какие хорошие?

• Решение найдено, но эффективно ли оно?

• Как отразится оптимизация одного функционального блока на работоспособности и производительности остальных?

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

Анализ результатов тестирования на прототипе

Методика выглядит следующим образом:

• Создаются две копии рабочей информационной базы – «Как есть» и «Как будет». В конфигурацию «Как есть» никаких изменений не вносится.

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

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

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

Понятно, что ни одно предприятие не позволит отвлекать всех пользователей своей информационной системы на эксперименты по оптимизации, поскольку такая «массовка» – выбрасывание денег в мусорную корзину в буквальном смысле. Но реальные пользователи нам и не потребуются. «Симулятор предприятия» можно построить при помощи двух других инструментов, также входящих в состав «1С: Корпоративный инструментальный пакет 8».

• Конфигурация «Тест-центр». Представляет собой готовую инфраструктуру для хранения, настройки и автоматизированного выполнения тестовых сценариев, а также для сбора и анализа результатов тестирования (этот инструмент мы рассматривали в предыдущей статье нашего цикла).

• Эмуляция работы пользователей по вводу документов. Комплект обработок позволяет проанализировать действия пользователей в информационной базе за произвольный промежуток времени и сформировать на основании этих действий сценарий для «Тест-центра».

Тестовый сценарий, сформированный таким образом, будет не просто близок к реальности, он будет «дословно» повторять все операции по вводу и проведению документов, которые выполнялись реальными пользователями.

В целях ускорения тестов можно использовать «коэффициент сжатия времени» (пропорциональное

Добавить отзыв
ВСЕ ОТЗЫВЫ О КНИГЕ В ИЗБРАННОЕ

0

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

Отметить Добавить цитату
×