В последнее время результаты опросов о важнейших для пользователя характеристиках платформ и решений ECM/СЭД стабильно выводят на первое место такие параметры, как быстродействие и удобство интерфейса.

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

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

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

За что разработчик платит быстродействием?

Проектируя любую платформу ECM/СЭД, разработчик стремится «втиснуть» в нее как можно больше готовой прикладной функциональности, чтобы создавать решения на платформе было быстрее, проще и надежнее, и чтобы разработчик решения мог целиком сосредоточиться на бизнес-задаче заказчика. Конечная цель - повысить ценность системы для заказчика.

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

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

Ничего нового в этих соображениях нет. За любую сложность приходится платить. В случае бизнес-платформ платить приходится быстродействием.

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

Как измеряется быстродействие платформы?

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

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

Нормативы быстродействия

Например, приказом Минкомсвязи 221 от 2011 года описаны требования доступа к системе электронного документооборота. В них нормативное время отклика системы устанавливается не более 3 секунд. С нормами времени отклика программы в разных ситуациях нужно разобраться, осознавая при этом, что идеальным временем отклика вовсе не будет 0 секунд. Кто не верит – вспомните, что на смартфонах очень широко используется анимация, хотя добиться там выдачи результата за 0 секунд не проблема. Я специально попробовал отключить анимацию в приложении для чтения Google Play Books – страница заменяется мгновенно, но от такого чтения быстро начинает болеть голова, если палец дрогнет можно пролистнуть сразу несколько страниц и потом с недоумением вчитываться в текст.

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

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

Теперь надо разобраться с тем, что нужно мерять для определения быстродействия. Ответ, казалось бы, очевиден – то самое время отклика программы и нужно измерить. Но если мы говорим о платформе СЭД/ECM, то с платформой пользователь практически никогда не работает, он имеет дело с прикладным решением на ее базе, и волнует его именно время отклика программы, с которой он работает. Простой пример – есть платформа разработки .NetFramework. С высокой вероятностью многие программы на вашем компьютере разработаны на этой платформе. Как вас, как конечного пользователя, может волновать быстродействие платформы?

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

При какой нагрузке измерять?

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

Вот пример действий пользователя в реальном проекте и измеренное в нагрузочном тестировании время исполнения операций (в секундах). В реальности в сценарий нагрузочного тестирования входят сотни операций.

И время отклика на каждой операции имеет значение. Предположим, мы измерили время каждой такой операции. Все? Уже можно оценивать на соответствие нормативу? Сравнивать одну программу с другой? Нет, еще нельзя. Потому что пользователь у нас не один, их много, они разные и все они работают в системе одновременно.

Подробнее о формировании сценариев нагрузочного тестирования можно посмотреть в статье «Быстродействие СЭД: разбираем методику оценки»

«А пользователи?»

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

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

Рисунок 1. Кривые деградации в нагрузочных испытаниях (пример)

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

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

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

На практике все гораздо сложнее – ведь быстродействие зависит не только от количества пользователей, но и от объема и структуры информации, хранящейся в системе. Есть и другие нюансы, например, об автоматизации нагрузочного тестирования. Для желающих углубиться в тему, можем порекомендовать нашу статью на Хабре `Практика автоматизации измерения показателей быстродействия СЭД`

Хорошая практика публикации результатов

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

Вот пример информации о быстродействия одной недавно появившейся российской платформы СЭД: «Открытие сложных карточек и переходы между этапами процессов менее 1 сек» (месяц назад на том же месте было написано 0.1 секунды).

Насколько менее? При какой нагрузке? Что такое сложная карточка? Какой сценарий измерялся? Доступна ли методика измерений? Доступен ли массив результатов измерений? Ничего этого нет.

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

Оптимизация быстродействия при стабилизации новой версии платформы

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

Как происходит борьба за быстродействие без снижения функциональности? Можем рассказать об этом на примере СЭД/ECM-платформы Docsvision.

Новая версия Docsvision 5 была самым большим функциональным скачком за всю историю продукта - это касалось, главным образом, перестройки бизнес-модели платформы с целью снизить время и затраты на разработку и модификацию решений (второй путь, перечисленный в начале статьи). Результаты функционального развития были хорошими, но быстродействие оказалась недостаточным. Можно было убрать некоторые из инноваций, а можно было начать глубокую оптимизацию. Мы выбрали второй путь, понимая, что для заказчика функциональность необходима, а быстродействие должно быть приемлемым (см. выше). Ни в коем случае не наоборот.

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

Рисунок 2. Снижение времени отклика системы по версиям. Последняя версия Docsvision 5.4 вышла в январе 2015 года, и в январе 2017 года мы подвели итоги оптимизации.

Нагрузочное тестирование производилось на встроенном приложении «Управление документами», реализующем типовые сценарии работы с документами и заданиями и широко использующемся у многих заказчиков.

Сегодня мы можем с уверенностью констатировать, что быстродействие версии 5.4 превзошло лучшие показатели предыдущей версии Docsvision 4.5, и поскольку мы годами публиковали и методики, и результаты тестирования – никто не скажет, что это голословные заявления

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

Связь быстродействия и масштабируемости

На графике с кривыми деградации (рисунок 1) видно, что по мере роста количества одновременных пользователей время отклика системы растет, пока не выйдет за границы приемлемого. Важно, чтобы численность ваших пользователей оказалась левее критической точки. И, как правило, увеличение вычислительной мощности не спасает ситуации – на практике, когда мощности перестает хватать, система не просто тормозит – она останавливается, виснет. Не хватает памяти на очереди ввода/вывода, организацию сеансовых соединений и т.п.

По причине роста зрелости крупных российских организаций и предприятий происходит рост спроса на решения ECM. ECM – это единое хранилище всех документов организации, независимо от того, в каких системах (СЭД, ERP, CRM и т.п.) они создавались.

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

Если в головном офисе даже очень крупных российских предприятий обычно не более 10 тысяч одновременных пользователей СЭД, то количество одновременных пользователей ECM во всех филиалах и дочерних обществах доходит до 100 тысяч и более. Распространенным трендом является централизация систем управления в распределенных организациях, раньше таких внедрений были единицы. Некоторые российские ECM-внедрения реализовывались на западных программных платформах (Documentum, Lotus Domino, FileNet, OpenText, Alfresco). Запрос на масштабируемость дополнительно усилился в условиях импортозамещения и снижения курса рубля, сегодня нужна замена, адекватная по масштабируемости и быстродействию.

Выводы

Для организаций и предприятий, выбирающих платформу реализации СЭД, мы рекомендуем:

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

·         Запросить у вендоров результаты нагрузочного тестирования актуальной версии и методику их измерения.

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

·         Начинать все-таки с выбора систем в короткий список по функциональности, а не по быстродействию.

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

Удачных проектов!

Автор: Сергей Пуцин, руководитель продуктового направления «ДоксВижн», июнь 2017