Поделиться
Быстродействие СЭД: разбираем методику оценки
Современные системы управления документооборотом и бизнес-процессами должны отвечать критически важному требованию - иметь адекватное быстродействие. Тем не менее, на рынке нет до сих пор сколько-нибудь устоявшихся методик расчета этого показателя. В свете этого актуально рассмотреть пример составления такой методики и реальные оценки проведенного по ней тестирования.Измерение времени выполнения операций
Для измерения времени выполнения операций использовалось средство автоматизированного тестирования TestComplete. Среда позволяет описать все сценарии, по которым выполняются измерения, прямо в терминах пользовательского интерфейса.
Архитектура испытательного стенда для тестирования производительности
Источник: DocsVision, 2010
Во время непосредственного выполнения тестирования все заранее сохраненные таким образом сценарии "проигрываются" на работающей системе определенное количество раз.
Вадим Ипатов, заместитель генерального директора по развитию бизнеса компании "Интертраст":
Каждый вендор платформы и поставщик прикладных решений должны обладать инструментарием и методологией тестирования быстродействия и масштабируемости СЭД. Сегодня недостаточно иметь только методы тестирования производительности и проводить нагрузочное тестирование. Современный подход к измерению производительности предполагает наличие постоянно действующего сервиса проактивного мониторинга, встроенного в систему и позволяющего контролировать появление узких мест и уведомлять об этом службу администрирования.
Чтобы обеспечить достаточную точность измерения таких величин, замеры нужно проводить несколько раз, чтобы исключить случайную погрешность. В этой связи DocsVision провела 5 независимых измерений для каждого сценария и усреднила полученные результаты.
Измерив скорость выполнения (и вторичные метрики) для некоторого набора операций, можно сделать вывод, какие из них не укладываются в заявленные рамки и нуждаются в оптимизации. Оптимизация может заключаться в модификациях исходного кода, направленных на снижение количества вызовов и трафика, оптимизацию вычислительных алгоритмов для снижения нагрузки на аппаратные составляющие и т.п.
Результаты тестирования
Описанная выше методология тестирования позволила выполнить сравнение показателей быстродействия между разными версиями системы, с тем чтобы определить эффективность произведенных улучшений и оптимизаций.
Результаты сравнения быстродействия двух версий системы DocsVision – 4.3 и 4.5* **
| Сценарий | Время выполнения основных сценариев, сек | |||||
| 4.3 | 4.5 | |||||
| Скорость канала | Скорость канала | |||||
| 100 Mbps | 512 kbps | 128 kbps | 100 Mbps | 512 kbps | 128 kbps | |
| Запуск системы (Навигатора) | 3,6 | 17,8 | 70,9 | 2,9 | 3,4 | 7,03 |
| Развертывание дерева папок (2000 папок) | 16 | 65 | 260 | 4,3 | 5,0 | 11,2 |
| Отображение дайджеста на папке с 70000 карточек | 17 | 17 | 23 | 7 | 7 | 7 |
| Отображение сложного представления на папке с 10000 карточек | 5 | 6 | 21 | 3 | 3 | 6 |
| Создание регистрационной карточки АДП |
3,5 | 7 | 20 | 0,8 | 1 | 1,4 |
| Открытие регистрационной карточки АДП | 2 | 3 | 9 | 0,7 | 0,8 | 1 |
| Создание карточки задания АДП | 2 | 2,5 | 4 | 0,5 | 0,6 | 1,2 |
* В данной версии системы были проведены работы по оптимизации производительности
** Измерения производительности выполнялись в следующей инфраструктуре:
1. Клиент: Intel Сore2 CPU 6420 2.1 GHz, 2Gb RAM, Win 2003 Server
2. AppServer+SQL Server (на одной машине): Intel Core 2 Duo CPU E8500, 3.16 GHz, 4 GB RAM, Windows 2008 Server R2 x64, SQL Server 2008 SP1.
Источник: Docsvision, 2010
Таким образом, в результате работ по оптимизации быстродействия в версии DocsVision 4.5 удалось значительно сократить время выполнения основных сценариев.
Елена Шелястина, технический директор компании "Летограф":
Методика проведения теста, по всей видимости, дает возможность проверить систему только в работе с большим числом документом. Фактически, при таком тестировании не создается реалистичная нагрузка (которая полностью моделировала бы реальные пиковые нагрузки СЭД), когда систему "атакуют" малоквалифицированные пользователи с многочисленных компьютеров, обращаясь к многочисленным документам.
Среднее ускорение сценариев на версии 4.5 произошло в 2, 4 и в 8 раз, соответственно для каналов 100 Мб/с, 512 Кб/с и 128 Кб/с,наиболее значительный рост быстродействия произошел на медленных соединениях 128 Кб/с). При этом максимальное ускорение быстродействие для развертывания дерева папок на скорости 128 Кб/с составило более 20 раз.
Ускорение работы системы было получено в основном путем сокращения количества серверных вызовов и трафика клиент-сервер при оптимизации кода системы.
Нагрузочное тестирование
Для получения оценки соответствия конкретной аппаратной и программной инфраструктуры прогнозируемой нагрузке необходимо, прежде всего, выявить ключевые требования по предполагаемой инфраструктуре, а также характеристики нагрузки.
С этой целью выполняется обследование конкретных условий внедрения, в ходе которых фиксируются параметры аппаратно-программной инфраструктуры, схожей с предполагаемой при внедрении (аппаратные характеристики серверов, клиентов, пропускная способность сети, программная инфраструктура, и т.д.) и основные сценарии работы пользователей в системе (модели пользователей).
Модель пользователя
Очевидно, что в зависимости от специфики деятельности конкретной организации, варианты использования ПО в ней могут иметь существенные отличия от аналогичных предприятий.
Пример профиля пользователя ("Делопроизводитель")
- Вход в систему – 2-3 раза в день
- Регистрация входящих документов – 20-30 раз в день
- Создание резолюций – 5-8 раз в день
- Открытие файлов до 1 Мб – 10-12 раз в день, более 1 Мб – 2-3 раза
Некоторые могут использовать такие системы просто в качестве хранилища совместных файлов (ECM); другие делают акцент на автоматизации бизнес-процессов (Workflow); третьи – пользуются исключительно канцелярскими функциями и т.д.
Очевидно, что каждый из видов такой деятельности затрагивает специфические функции системы и, соответственно, создает различную нагрузку. Таким образом, для более точного моделирования поведения системы в конкретных условиях необходимо как можно более подробно и точно описать все варианты ее использования.
Алексей Чудаков, руководитель лаборатории ЕВФРАТ Cognitive Technologies:
Предложенная методика может использоваться для тестирования быстродействия одного конкретного продукта. В этом случае показатели сравниваются с предыдущими и такая оценка достаточно объективна. Когда речь идет о сравнении быстродействия разных СЭД, то использование подобной методики не дает однозначного ответа.
Для нагрузочного тестирования важным вопросом является частота применения пользователями выделенных сценариев работы. Для этого используется профилирование пользователей.
Таких профилей, в зависимости от вариантов применения системы, может быть несколько. Все они должны быть схожим образом сформулированы для определения общей частоты использования сценариев для нагрузочного тестирования.
Нагрузочная модель для предприятия с 4000 пользователями
| Сценарий | Роли пользователей | Число за 8 часов | Частота использования сценария, % | Число в минуту |
| Создание регистрационной карточки (РК), привязка к 2 м РК, заполнение 5 согласующих лиц | Исполнители при создании внутренних и исходящих документов | 3 333 | 1% | 7 |
| Открытие РК, открытие и сохранение измененного файла (1 Мбайт). | 1. Исполнители при создании внутренних и исходящих документов (до 10 на один документ) 2. Согласующие лица (до 2 циклов согласования с 5 лицами) |
133 |
55% | 278 |
| Открытие РК, присвоение регистрационного номера, присоединение образа документа и сохранение | Секретари при регистрации внутренних и исходящих документов | 6 667 | 3% | 14 |
| Создание РК, поиск повторной регистрации, приявязка к 2 другим РК, присоединение образа документа и присвоение регистрационного номера | Регистраторы при регистрации входящих документов | 3 333 | 1% | 7 |
| Просмотр РК (по всем закладкам и дерева резолюций) | Сотрудники для подготовки других документов или поиске материалов (до 5 документов на каждый исходящий или внутренний) | 33 |
14% | 69 |
| Открытие РК, создание резолюции на 3 подчиненных | Помощник, руководитель при расписании резолюции | 3 333 | 1% | 7 |
| Открытие резолюции и расписание резолюции на 3 подчиненных | Помощник, руководитель при расписании резолюции | 30 000 | 12% | 63 |
| Открытие резолюции и ввод информации о ходе исполнения | Исполнение резолюции (1 раз для каждой резолюции в неделю) | 30 000 | 12% | 63 |
| 243 |
507 | |||
| Сценарии фильтрации представлений | ||||
| Фильтрация входящих (до 100 записей) | Один раз в полчаса каждым пользователем в течение дня | 64 000 | 8% | 133 |
| Фильтрация входящей корреспонденции в подразделение (до 200 записей) | Один раз в полчаса каждым секретарем в течение дня | 7 840 | 1% | 16 |
| Фильтры выборки для отчета (по диапазону дат, подразделению) (до 1000 записей) | Секретари, руководители подразделений (10 раз в день) | 4 900 | 1% | 10 |
| Фильтры статистической выборки (по диапазону дат, с группировкой по подразделению, виду документа) (группировка 10000 записей) | Секретари, руководители подразделений - навигация по статистическим отчетам (100 в день на каждого) | 49 000 | 6% | 102 |
| Поиск по справочнику сотрудников (100.000 записей, результат 10 записей) | 50 раз каждый пользователь в день, 10 раз на каждый документ, 5 раз на каждую резолюцию, 2 раза на каждый отчет | 459 |
56% | 958 |
| Поиск по справочнику контрагентов (200.000 записей, результат 10 записей) | 50 раз каждый пользователь в день, 3 раза на каждый документ, 2 раза на каждый отчет | 239 |
29% | 500 |
| 825 |
1 719 | |||
Источник: DoscVision, 2010
Следующим шагом является реализация данной модели пользователя в среде, которая будет использоваться для имитации нагрузки.
Дмитрий Романов, директор по развитию технологий информационного менеджмента "АйТи":
Сама идея проведения нагрузочного тестирования СЭД в условиях современного российского рынка представляется здравой и интересной, что демонстрирует зрелость самого вендора. Не понимая того, как твое решение будет вести себя в той или иной программно-аппаратной конфигурацией под разными видами нагрузки - не стоит вообще браться за проект и дискредитировать саму идею электронного документооборота.
В качестве такой среды использовался продукт Microsoft Visual Studio 9.0 (2008), который имеет встроенную подсистему описания и моделирования тестов. В данной среде необходимо описать каждую единичную операцию, выполняемую в рамках модели, в терминах программного кода (на языке C# или VB.NET). Для этого используется объектная модель (API) прикладной системы. Здесь важно как можно точнее запрограммировать эти операции, чтобы их реализация в исходном коде соответствовала по набору команд (и создаваемой ими нагрузке) той же операции, выполняемой через пользовательский интерфейс системы. Готовые блоки объединяются с помощью интерфейса Visual Studio в сценарии. Для каждой операции указывается частота ее выполнения и вероятность этого события. Эти скрипты могут быть целиком сформированы с использованием ранее описанных моделей пользователей и может быть несколько. Далее в ходе непосредственного тестирования каждый сценарий запускается в нескольких экземплярах, моделируя работу одного пользователя. Всего в среде Visual Studio возможно наличие до нескольких тысяч одновременно работающих скриптов (в зависимости от аппаратной мощности машины, на которой запускается такая нагрузка).
Короткая ссылка
