Практика автоматизації вимірювання показників швидкодії СЕД

Системи електронного документообігу та 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), які задовольняють наступним (хоча б одному) критеріями:
СЕД є основним робочим інструментом користувача;
  • Користувачі створюють документи і завдання;
  • Користувачі обробляють документи (наприклад, реєструють) та завдання (наприклад, завершують);
  • Користувачі розкривають різні вузли папок;
  • Користувачі відкривають стандартні і віртуальні папки.
При цьому: група покриває різні сценарії роботи користувачів у системі; обладнання робочих місць користувачів відповідає рекомендованим вимогам розробника; користувачі представляють різні умови роботи із СЕД з точки зору способів підключення (локальні з різних сегментів мережі, термінальні).

Доповнення

Не менш важливо при проведенні вимірювань:
• звернути увагу на контроль умов, при яких отримані показники швидкодії (вимірювання завантаження обладнання СЕД): клієнтські комп'ютери, мережеве з'єднання з сервером додатків, сервер.
• аналізувати дані по завантаженню устаткування при одержанні незадовільних показників швидкодії.
• проводити профілювання бази даних при виявленні повільних операцій з даними саме на серверах.

Висновок

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

У певних ситуаціях можливе використання тільки вбудованих інструментів: це, наприклад, може бути корисно при роботі «у поле» на стороні замовника, коли немає доступу до широкого кола інструментів і додатків.
Сторонні засоби діагностики варто використовувати вдумливо і порівнянно поставленим завданням.

Обклавшись цифрами і графіками, потрібно не відриватися від реальності. Бажано зберігати працездатність програми, щоб ефект від оптимізації після замірів — можна було помацати в бойових умовах.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.