Системы электронного документооборота и ERP-системы представляют собой комплексные программные продукты, чаще всего состоящие из множества подсистем. Части любой системы работают как непосредственно в диалоге с пользователем, так и фоновом режиме, выполняя определённую часть задач на сервере.
Чтобы контроль производительности системы проводился в обоих направлениях, администратору системы нужны удобные инструменты для замеров, позволяющие вовремя найти слабое звено и предпринять меры по улучшению быстродействия. В этой статье я поделюсь своим опытом в том, как можно решить вопрос автоматических замеров показателей быстродействия системы на примере системы электронного документооборота*.
В отличие от других программных продуктов, для СЭД существуют определённые требования по быстродействию: это один из важных параметров, за которым необходимо следить.
*Статья будет особенно полезна начинающим администраторам Docsvision, но в целом изложенный опыт применим и для аналогичных продуктов.
Скорость
Помимо функционала и дизайна, для любого программного обеспечения ключевой параметр – это скорость работы, и этот фактор является особенно существенным в случае сложной системы вроде систем электронного документооборота.
Представьте, что пользователю-делопроизводителю в рабочем процессе нужно оперативно выполнить целый ряд действий: открыть навигатор*, создать новые карточки и просмотреть существующие, прикрепить документы\файлы к карточкам, провести поиск по большому количеству документов, сформировать данные для отчётов. И сделать всё это нужно быстро.
Вернемся к истокам: чем обуславливается быстродействие системы?
В общем случае, скоростью работы каждого из звеньев приложения и скоростью взаимодействия между звеньями. В сложном ПО звеньев может быть много, тогда скорость работы будет пропорционально работе самого медленного звена.
Например, система электронного документооборота Docsvision представляет собой приложение с клиент-серверной архитектурой, и мы используем:
1. IIS в качестве веб сервера
2. MS SQL Server в качестве СУБД
3. Клиентское приложение, написанное на .NET и WCF
*Навигатор – так в Docsvision называется основное рабочее место пользователя СЭД.
Если совсем упростить: пользователь, работающий в клиентском приложении Docsvision Navigator, со своего рабочего места обменивается запросами с веб-сервером, получая/отправляя те или иные данные (это позволяет работать в Docsvision как в локальной сети, так и через интернет (http/https на выбор).
Сразу отмечу, что для приложений, которые используют IIS (Apache, NGINX) в качестве веб сервера и MS SQL в качестве СУБД, приведённые в статье рекомендации будут также актуальны.
Если мы вернёмся к перечисленным задачам делопроизводителя, все они (и не только они) выполняются с разной скоростью, и все их можно при желании замерить для выяснения степени быстродействия системы.
Как правило, производители ПО изначально предоставляют данные по основным показателям быстродействия. К примеру, перечень основных показателей (и их значений для соответствующей версии Docsvision 5) официально публикуются компанией «ДоксВижн» в документе «Руководство по установке и администрированию Docsvision 5».
В эти показатели входят:
• Запуск Навигатора («холодный» старт)
• Открытие карточки документа УД (первое после запуска Навигатора)
• Открытие карточки документа УД (последующие)
• Открытие карточки задания УД (первое после запуска Навигатора)
• Открытие карточки задание УД (последующие)
Значения этих показателей получаются опытным путем на нагрузочном полигоне в ходе нагрузочного тестирования для 500 одновременно работающих пользователей. Подробно о методике выполнения нагрузочного тестирования СЭД можно прочитать в статье на сайте «ДоксВижн»: www.docsvision.com/testirovanie-sed-docsvision-5 А также в нашем предыдущем посте на Хабре: habrahabr.ru/company/docsvision/blog/225129
Способы измерения
Как проверить самостоятельно соответствие внедрённой системы заявленным показателям производителя? На базе нашего собственного опыта, а также опыта наших партнёров, сформировался ряд инструментов и рекомендаций для оптимального выполнения этой задачи.
Можно вооружиться секундомером для измерения, например, времени открытия клиентского приложения («Навигатора»), но это не совсем профессиональный подход. Мы будем использовать знакомые каждому веб-разработчику утилиту:
Fiddler
Так как клиентское приложение обращается к веб-серверу, мы будем использовать утилиту Fiddler (http://www.telerik.com/fiddler)
В данном случае fiddler выступает в качестве прокси-сервера, через который проходят все клиентские запросы (здесь нас интересуют запросы от приложения Docsvision Navigator).
Так достаточно удобно смотреть на скорость выполнения запросов, и, что немаловажно, эту информацию можно использовать в качестве диагностики проблем производительности. Можно с большой точностью сказать, где имеется замедление на клиенте (слабое «железо», плохой сетевой канал, медленная прорисовка интерфейса) или на сервере.
Fiddler позволяет выяснить следующее:
1. Количество серверных вызовов.
2. Длительность серверных вызовов.
3. Характер вызываемой серверной логики.
4. Распределение серверных вызовов во времени.
5. Распределение времени работы сценария между клиентом и сервером (очень полезно узнать, где именно производительность просела).
JetBrains dotTrace Performance
Наши коллеги (по части разработки ПО) из JetBrains разрабатывают достаточно много полезного инструментария для разработчиков. Одно из приложений можно использовать для анализа показателей быстродействия системы.
DotTrace — проприетарный профилировщик для отслеживания проблем производительности и узких мест использования памяти в приложениях на платформе .NET
Этот инструмент достаточно мощный и позволяет:
1. Использовать несколько режимов профилирования (в том числе, изменение времени выполнения потока подпрограммы).
2. Сравнивать снимки («трейсы»), снятые с разных систем (в некоторых случаях полезно сравнить снимки двух клиентских рабочих мест).
3. Вести статистику по используемым функциям и времени их выполнения (узнать, что именно сработало неоптимально – поиск папки или предпросмотр файла).
4. Профилировать занятую в системе память.
В разрезе Docsvision: во время поиска проблем производительности мы рекомендуем профилировать и анализировать (с нашей помощью) как клиентские, так и серверные компоненты платформы. Данный инструмент используют в основном разработчики для диагностирования проблемных сценариев в работе.
Лог навигатора
Если под рукой ничего нет, то анализ приложения можно провести, используя собственные средства. У приложения есть возможность включить свой собственный диагностический лог.
Чаще всего диагностический лог навигатора используется для локализации ошибок в работе, но кроме этого он содержит информацию обо всех операциях, выполняемых приложением «Docsvision Навигатор». Т.е. логгируются только клиентские операции конкретного приложения, для которого ведётся лог.
Примерно так выглядит сам лог:
В логе следует обратить внимание на:
• Открытие навигатора
• Штатное закрытие навигатора (в паре с операцией «Открытие навигатора» даёт косвенную информацию о событиях аварийного завершения Навигатора)
• Длительность открытия навигатора
• Длительность открытия карточки
• Длительность раскрытия узла папки
• Длительность построения представления в папке
Поскольку читать лог, используя текстовые редакторы, не всегда удобно, администраторам Docsvision можно воспользоваться утилитой Docsvision Navigator Log Parser. Это наша собственная разработка, которую можно запросить у сотрудников техподдержки.
Она приятна тем, что:
• упрощает процесс анализа расширенного лога навигатора, вычленяя только информацию о полезных операциях;
• умеет разделять первое (первое после операции Navigator started) и последующие открытия карточек документов и заданий;
• умеет выделять операции в заданном диапазоне времени/дат;
• результат обработки расширенного лога навигатора выводится в отдельный файл csv для дальнейшего более детального анализа.
Серверная часть
В ходе исследований клиентского приложения на предмет быстродействия может так случиться, что, проанализировав данные клиентских приложений и обнаружив отсутствие проблем, необходимо провести аудит серверной части (СУБД). В этом случае необходимо будет провести профилирование серверной части, основное внимание уделяя типичным инструментам администратора MS SQL.
SQL SERVER profiler
Стандартная утилита администраторов SQL-сервера позволяет посмотреть абсолютно все запросы ко всем базам, находящимся в вашем владении.
С использованием определённых шаблонов профилирования можно получить много полезной информации:
1. Узнать, какие операции в БД и с какой длительностью выполняются
2. Узнать о наличии мёртвых блокировок (Deadlocks)
3. Узнать план выполнения запросов и хранимых процедур
Конечно же, эти методы применимы не только к БД Docsvision, но и к любой БД на SQL. Собранные таким образом данные помогают не только увидеть скорость работы тех или иных операций, но и натолкнуть Администратора Docsvision (вместе с DBA) на шаги к оптимизации производительности. На самом деле, эта тема довольная обширная, и подходит для отдельной статьи. Администраторы MSSQL, вооружившись SQL Profiler и Database Tuning Advisor, могут применить свои знания на практике, оптимизировав работу БД.
Объективность и репрезентативность измерений
Для получения точных результатов при проведении измерений, рекомендую учитывать следующие факторы.
• Репрезентативность. Достаточно проанализировать показатели группы пользователей без необходимости анализировать показатели на всех рабочих местах.
• Объективность. Измеряемые показатели должны быть выражены количественно и посчитаны без влияния субъективных факторов в автоматическом режиме. Это, например, отказ «железной» части или проблемы в стороннем ПО, мешающем работе (антивирусное ПО, файрволы, сетевые маршрутизаторы point-to-point).
• Выборка пользователей.
При проведении измерений в СЭД достаточно выбрать активных пользователей (целесообразно до 10), удовлетворяющих следующим (хотя бы одному) критериям:
СЭД является основным рабочим инструментом пользователя;
При этом: группа покрывает различные сценарии работы пользователей в системе; оборудование рабочих мест пользователей соответствует рекомендуемым требованиям разработчика ПО; пользователи представляют разные условия работы с СЭД с точки зрения способов подключения (локальные из разных сегментов сети, терминальные).
Дополнения
Не менее важно при проведении измерений:
• обратить внимание на контроль условий, при которых получены показатели быстродействия (измерение загрузки оборудования СЭД): клиентские компьютеры группы, сетевое соединение с сервером приложений, сервера.
• анализировать данные по загрузке оборудования при получении неудовлетворительных показателей быстродействия.
• проводить профилирование базы данных при выявлении медленных операций с данными именно на серверах.
Заключение
Для замеров производительности используются не только собственно разработанные инструменты (логгирование, встроенное в платформу), но и широкий круг знакомых приложений, которые за короткое время помогут провести диагностику рабочих мест.
В определённых ситуациях возможно использование только встроенных инструментов: это, например, может быть полезно при работе «в поле» на стороне заказчика, когда нет доступа к широкому кругу инструментов и приложений.
Сторонние средства диагностики стоит использовать вдумчиво и соизмеримо поставленным задачам.
Обложившись цифрами и графиками, нужно не отрываться от реальности. Желательно сохранять работоспособность приложения, чтобы эффект от оптимизации после замеров — можно было пощупать в боевых условиях.
Чтобы контроль производительности системы проводился в обоих направлениях, администратору системы нужны удобные инструменты для замеров, позволяющие вовремя найти слабое звено и предпринять меры по улучшению быстродействия. В этой статье я поделюсь своим опытом в том, как можно решить вопрос автоматических замеров показателей быстродействия системы на примере системы электронного документооборота*.
В отличие от других программных продуктов, для СЭД существуют определённые требования по быстродействию: это один из важных параметров, за которым необходимо следить.
*Статья будет особенно полезна начинающим администраторам Docsvision, но в целом изложенный опыт применим и для аналогичных продуктов.
Скорость
Помимо функционала и дизайна, для любого программного обеспечения ключевой параметр – это скорость работы, и этот фактор является особенно существенным в случае сложной системы вроде систем электронного документооборота.
Представьте, что пользователю-делопроизводителю в рабочем процессе нужно оперативно выполнить целый ряд действий: открыть навигатор*, создать новые карточки и просмотреть существующие, прикрепить документы\файлы к карточкам, провести поиск по большому количеству документов, сформировать данные для отчётов. И сделать всё это нужно быстро.
Вернемся к истокам: чем обуславливается быстродействие системы?
В общем случае, скоростью работы каждого из звеньев приложения и скоростью взаимодействия между звеньями. В сложном ПО звеньев может быть много, тогда скорость работы будет пропорционально работе самого медленного звена.
Например, система электронного документооборота Docsvision представляет собой приложение с клиент-серверной архитектурой, и мы используем:
1. IIS в качестве веб сервера
2. MS SQL Server в качестве СУБД
3. Клиентское приложение, написанное на .NET и WCF
*Навигатор – так в Docsvision называется основное рабочее место пользователя СЭД.
Если совсем упростить: пользователь, работающий в клиентском приложении Docsvision Navigator, со своего рабочего места обменивается запросами с веб-сервером, получая/отправляя те или иные данные (это позволяет работать в Docsvision как в локальной сети, так и через интернет (http/https на выбор).
Сразу отмечу, что для приложений, которые используют IIS (Apache, NGINX) в качестве веб сервера и MS SQL в качестве СУБД, приведённые в статье рекомендации будут также актуальны.
Если мы вернёмся к перечисленным задачам делопроизводителя, все они (и не только они) выполняются с разной скоростью, и все их можно при желании замерить для выяснения степени быстродействия системы.
Как правило, производители ПО изначально предоставляют данные по основным показателям быстродействия. К примеру, перечень основных показателей (и их значений для соответствующей версии Docsvision 5) официально публикуются компанией «ДоксВижн» в документе «Руководство по установке и администрированию Docsvision 5».
В эти показатели входят:
• Запуск Навигатора («холодный» старт)
• Открытие карточки документа УД (первое после запуска Навигатора)
• Открытие карточки документа УД (последующие)
• Открытие карточки задания УД (первое после запуска Навигатора)
• Открытие карточки задание УД (последующие)
Значения этих показателей получаются опытным путем на нагрузочном полигоне в ходе нагрузочного тестирования для 500 одновременно работающих пользователей. Подробно о методике выполнения нагрузочного тестирования СЭД можно прочитать в статье на сайте «ДоксВижн»: www.docsvision.com/testirovanie-sed-docsvision-5 А также в нашем предыдущем посте на Хабре: habrahabr.ru/company/docsvision/blog/225129
Способы измерения
Как проверить самостоятельно соответствие внедрённой системы заявленным показателям производителя? На базе нашего собственного опыта, а также опыта наших партнёров, сформировался ряд инструментов и рекомендаций для оптимального выполнения этой задачи.
Можно вооружиться секундомером для измерения, например, времени открытия клиентского приложения («Навигатора»), но это не совсем профессиональный подход. Мы будем использовать знакомые каждому веб-разработчику утилиту:
Fiddler
Так как клиентское приложение обращается к веб-серверу, мы будем использовать утилиту Fiddler (http://www.telerik.com/fiddler)
В данном случае fiddler выступает в качестве прокси-сервера, через который проходят все клиентские запросы (здесь нас интересуют запросы от приложения Docsvision Navigator).
Так достаточно удобно смотреть на скорость выполнения запросов, и, что немаловажно, эту информацию можно использовать в качестве диагностики проблем производительности. Можно с большой точностью сказать, где имеется замедление на клиенте (слабое «железо», плохой сетевой канал, медленная прорисовка интерфейса) или на сервере.
Fiddler позволяет выяснить следующее:
1. Количество серверных вызовов.
2. Длительность серверных вызовов.
3. Характер вызываемой серверной логики.
4. Распределение серверных вызовов во времени.
5. Распределение времени работы сценария между клиентом и сервером (очень полезно узнать, где именно производительность просела).
JetBrains dotTrace Performance
Наши коллеги (по части разработки ПО) из JetBrains разрабатывают достаточно много полезного инструментария для разработчиков. Одно из приложений можно использовать для анализа показателей быстродействия системы.
DotTrace — проприетарный профилировщик для отслеживания проблем производительности и узких мест использования памяти в приложениях на платформе .NET
Этот инструмент достаточно мощный и позволяет:
1. Использовать несколько режимов профилирования (в том числе, изменение времени выполнения потока подпрограммы).
2. Сравнивать снимки («трейсы»), снятые с разных систем (в некоторых случаях полезно сравнить снимки двух клиентских рабочих мест).
3. Вести статистику по используемым функциям и времени их выполнения (узнать, что именно сработало неоптимально – поиск папки или предпросмотр файла).
4. Профилировать занятую в системе память.
В разрезе Docsvision: во время поиска проблем производительности мы рекомендуем профилировать и анализировать (с нашей помощью) как клиентские, так и серверные компоненты платформы. Данный инструмент используют в основном разработчики для диагностирования проблемных сценариев в работе.
Лог навигатора
Если под рукой ничего нет, то анализ приложения можно провести, используя собственные средства. У приложения есть возможность включить свой собственный диагностический лог.
Чаще всего диагностический лог навигатора используется для локализации ошибок в работе, но кроме этого он содержит информацию обо всех операциях, выполняемых приложением «Docsvision Навигатор». Т.е. логгируются только клиентские операции конкретного приложения, для которого ведётся лог.
Примерно так выглядит сам лог:
В логе следует обратить внимание на:
• Открытие навигатора
• Штатное закрытие навигатора (в паре с операцией «Открытие навигатора» даёт косвенную информацию о событиях аварийного завершения Навигатора)
• Длительность открытия навигатора
• Длительность открытия карточки
• Длительность раскрытия узла папки
• Длительность построения представления в папке
Поскольку читать лог, используя текстовые редакторы, не всегда удобно, администраторам Docsvision можно воспользоваться утилитой Docsvision Navigator Log Parser. Это наша собственная разработка, которую можно запросить у сотрудников техподдержки.
Она приятна тем, что:
• упрощает процесс анализа расширенного лога навигатора, вычленяя только информацию о полезных операциях;
• умеет разделять первое (первое после операции Navigator started) и последующие открытия карточек документов и заданий;
• умеет выделять операции в заданном диапазоне времени/дат;
• результат обработки расширенного лога навигатора выводится в отдельный файл csv для дальнейшего более детального анализа.
Серверная часть
В ходе исследований клиентского приложения на предмет быстродействия может так случиться, что, проанализировав данные клиентских приложений и обнаружив отсутствие проблем, необходимо провести аудит серверной части (СУБД). В этом случае необходимо будет провести профилирование серверной части, основное внимание уделяя типичным инструментам администратора MS SQL.
SQL SERVER profiler
Стандартная утилита администраторов SQL-сервера позволяет посмотреть абсолютно все запросы ко всем базам, находящимся в вашем владении.
С использованием определённых шаблонов профилирования можно получить много полезной информации:
1. Узнать, какие операции в БД и с какой длительностью выполняются
2. Узнать о наличии мёртвых блокировок (Deadlocks)
3. Узнать план выполнения запросов и хранимых процедур
Конечно же, эти методы применимы не только к БД Docsvision, но и к любой БД на SQL. Собранные таким образом данные помогают не только увидеть скорость работы тех или иных операций, но и натолкнуть Администратора Docsvision (вместе с DBA) на шаги к оптимизации производительности. На самом деле, эта тема довольная обширная, и подходит для отдельной статьи. Администраторы MSSQL, вооружившись SQL Profiler и Database Tuning Advisor, могут применить свои знания на практике, оптимизировав работу БД.
Объективность и репрезентативность измерений
Для получения точных результатов при проведении измерений, рекомендую учитывать следующие факторы.
• Репрезентативность. Достаточно проанализировать показатели группы пользователей без необходимости анализировать показатели на всех рабочих местах.
• Объективность. Измеряемые показатели должны быть выражены количественно и посчитаны без влияния субъективных факторов в автоматическом режиме. Это, например, отказ «железной» части или проблемы в стороннем ПО, мешающем работе (антивирусное ПО, файрволы, сетевые маршрутизаторы point-to-point).
• Выборка пользователей.
При проведении измерений в СЭД достаточно выбрать активных пользователей (целесообразно до 10), удовлетворяющих следующим (хотя бы одному) критериям:
СЭД является основным рабочим инструментом пользователя;
- Пользователи создают документы и задания;
- Пользователи обрабатывают документы (например, регистрируют) и задания (например, завершают);
- Пользователи раскрывают различные узлы папок;
- Пользователи открывают стандартные и виртуальные папки.
При этом: группа покрывает различные сценарии работы пользователей в системе; оборудование рабочих мест пользователей соответствует рекомендуемым требованиям разработчика ПО; пользователи представляют разные условия работы с СЭД с точки зрения способов подключения (локальные из разных сегментов сети, терминальные).
Дополнения
Не менее важно при проведении измерений:
• обратить внимание на контроль условий, при которых получены показатели быстродействия (измерение загрузки оборудования СЭД): клиентские компьютеры группы, сетевое соединение с сервером приложений, сервера.
• анализировать данные по загрузке оборудования при получении неудовлетворительных показателей быстродействия.
• проводить профилирование базы данных при выявлении медленных операций с данными именно на серверах.
Заключение
Для замеров производительности используются не только собственно разработанные инструменты (логгирование, встроенное в платформу), но и широкий круг знакомых приложений, которые за короткое время помогут провести диагностику рабочих мест.
В определённых ситуациях возможно использование только встроенных инструментов: это, например, может быть полезно при работе «в поле» на стороне заказчика, когда нет доступа к широкому кругу инструментов и приложений.
Сторонние средства диагностики стоит использовать вдумчиво и соизмеримо поставленным задачам.
Обложившись цифрами и графиками, нужно не отрываться от реальности. Желательно сохранять работоспособность приложения, чтобы эффект от оптимизации после замеров — можно было пощупать в боевых условиях.
