Поделиться
Быстродействие СЭД: разбираем методику оценки
Современные системы управления документооборотом и бизнес-процессами должны отвечать критически важному требованию - иметь адекватное быстродействие. Тем не менее, на рынке нет до сих пор сколько-нибудь устоявшихся методик расчета этого показателя. В свете этого актуально рассмотреть пример составления такой методики и реальные оценки проведенного по ней тестирования.В системах электронного документооборота и управления бизнес-процессами быстродействие является одним из важнейших потребительских свойств системы.
При этом ожидания пользователя достаточно высоки – система не должна выглядеть существенно медленнее других используемых менеджером приложений – 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, и позволяют сохранить значения метрик за весь период тестирования и представить результаты в виде удобных графиков. Впоследствии с помощью данных метрик можно оценить, какие операции (из выполнявшихся в ходе тестирования) вызывали наибольшую нагрузку; и какая аппаратная часть (процессор, память, диск) на каждом из уровней является "узким местом" в быстродействии всей системы.
Для автоматизации процесса измерения метрик и получения оценки максимально возможной скорости отклика системы в типовых схемах работы необходимо сделать подробное описание каждого сценария уже в терминах интерфейса системы (последовательность нажатия кнопок и выполнения команд, необходимая для достижения цели). Необходимо также определить рамки измерений.
Короткая ссылка
