Спецпроекты

Быстродействие СЭД: разбираем методику оценки

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

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

При этом ожидания пользователя достаточно высоки – система не должна выглядеть существенно медленнее других используемых менеджером приложений – Microsoft Office, Internet Explorer, интернет-почта. Реальное быстродействие системы при этом действует как ограничение спроса на нее, в отличие от функциональности. Конкретная функция может кому-то и не требоваться, не быть критичной, и ее отсутствие снизит спрос на систему только частично, в то время как недостаточное быстродействие может быстро вытеснить продукт с рынка.

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

Критичность быстродействия

Осенью 2009 года компания DocsVision провела исследование важности потребительских свойств системы, опросив своих клиентов и партнеров. В анкете каждому участнику предлагалось оценить несколько свойств СЭД как "критичные", "важные" или "неважные".

Оценка важности потребительских свойств системы

Качество Критично Важно Неважно
Быстродействие 73% 27% 0%
Удобный, простой и понятный интерфейс 55% 45% 0%
Широкая функциональность 28% 60% 12%

DocsVision, 2009

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

Создание методологии

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

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

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

Требования к быстродействию

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

Примеры сценариев работы пользователя (на уровне платформы):

  • Запуск пользовательского интерфейса (навигатора) системы;
  • Открытие встроенных справочников системы;
  • Атрибутивный поиск;
  • Операции экспорта представлений и журналов;
  • Создание карточки со 100 свойствами;
  • Добавление, сохранение и удаление файлов (размером от 100Кб до 10Мб);
  • Отображение папок по дайджесту и представлению (содержащих от 10 до 70 000 строк)

Всего было выделено около 30 сценариев.

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

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

Поскольку DocsVision является платформой для задач СЭДО и управления бизнес-процессами, то пользователь часто работает не с самой платформой, а с приложением, построенным на ее базе. Поэтому правильно разделить сценарии между платформой и приложением и выбрать достаточно типичный продукт. Компания использовала для моделирования приложение DocsVision "Административное делопроизводство". Задача управления быстродействием решалась одновременно и для платформы и для приложения, при этом оптимизации подвергся код как того, так и другого.

Исследование литературы по требованиям к быстродействию офисных приложений показало, что для таких систем приемлемым считается быстродействие сценариев на уровне 3 секунд, и хорошим - на уровне 1,5 секунд. Эти значения использовались в качестве целей при оптимизации кодов платформы и приложения.

Задачи измерения быстродействия

Факторы, влияющие на быстродействие системы, естественным образом разделяются на две группы. Первая группа - факторы инфраструктуры (архитектура и качества кода программного обеспечения системы, вычислительная инфраструктура серверов, рабочих станций и сетей передачи данных). Вторая группа - факторы нагрузки в конкретном внедрении (количество одновременно работающих пользователей, частота применения ими различных сценариев).

Цели тестирования

Тестирование производительности* Оценка влияния инфраструктуры (аппаратного и программного обеспечения) на быстродействие системы.
Оценка максимально возможной скорости отклика системы в типовых сценариях, и соответствия этих показателей предъявляемым требованиям "в идеальных условиях".
Нагрузочное тестирование Оценка соответствия конкретной аппаратной и программной инфраструктуры прогнозируемой нагрузке.
Оценка влияния нагрузки на быстродействие в "в реальных условиях".

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

Источник: Docsvision, 2010

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

Тестирование производительности

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

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

Специально для теста искусственно занижалась пропускная способность сетевого канала между клиентом и сервером приложений (с этой целью использовалась утилита NetLimiter) в пограничных диапазонах 128 кб/с/512 кб/с/1 Мб/с. Кроме того, можно варьировать и иные аппаратные составляющие: объем оперативной памяти и частоту процессора на клиентском компьютере; тип дискового массива на сервере базы данных; и т.д.

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

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

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

Дополнительные метрики

  • Количество клиент-серверных вызовов, выполняющихся в рамках каждого сценария. Данный показатель важен, прежде всего, в условиях низкоскоростных сетевых каналов, и позволяет выделить сценарии, которые в таких условиях будут работать неэффективно. Количество вызовов измерялось с помощью утилиты Fiddler2, которая позволяет отслеживать и фиксировать все вызовы по протоколу http (и впоследствии детально анализировать весь трафик).
  • Количество входящего/исходящего трафика клиент-сервер порождаемого каждой операцией – не менее важный показатель для низкоскоростных каналов связи. Измерения выполнялись также с помощью утилиты Fiddler.

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

Данные метрики могут сниматься с помощью встроенного в ОС Windows средства Perfomance monitor, и позволяют сохранить значения метрик за весь период тестирования и представить результаты в виде удобных графиков. Впоследствии с помощью данных метрик можно оценить, какие операции (из выполнявшихся в ходе тестирования) вызывали наибольшую нагрузку; и какая аппаратная часть (процессор, память, диск) на каждом из уровней является "узким местом" в быстродействии всей системы.

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

Профиль месяца

Мы отказываемся от лоскутной автоматизации

Валерий Дьяченко

ИТ-директор «Мечела»

Персона месяца

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

Денис Чамара

ИТ-директор Санкт-Петербурга