Тестування продуктивності

ЗМІСТ
🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.

1. Вступ

1.1. Мета

Метою проведення тестування продуктивності є оцінка та перевірка продуктивності, надійності та масштабування платформи під різними сценаріями навантаження. За допомогою такого тестування виявляються "вузькі місця" та проблеми, які слід усунути, щоб покращити користувацький досвід. Тестування продуктивності також забезпечує здатність платформи та реєстрів на неї впоратись з передбачуваним обсягом користувачів або трансакцій, що здійснюються через виконання бізнес-процесів, отримання даних на інформаційних панелях та операцій створення, читання, оновлення та видалення з різними внутрішніми або зовнішніми сервісами або реєстрами.

1.2. Цілі

Основні цілі тестування продуктивності:

Забезпечення відповідності платформи та її реєстрів вимогам до навантаження

допомагає перевірити, чи система відповідає визначеним критеріям продуктивності, таким як кількість користувачів, що взаємодіють із системою, час відповіді, пропускна спроможність та використання ресурсів за нормальних та пікових умов навантаження.

Виявлення проблем з продуктивністю

дозволяє виявляти та аналізувати потенційні "вузькі місця" в платформі, які можуть негативно впливати на загальну продуктивність системи. Такі проблеми можуть включати неефективний код, неправильні конфігурації або обмеження апаратного забезпечення.

Оцінка масштабування

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

Забезпечення стабільності та надійності

перевіряє, чи здатні платформа та реєстри підтримувати стабільну продуктивність під безперервним, високим навантаженням протягом тривалого часу.

Надання рекомендацій щодо поліпшення продуктивності

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

Поліпшення користувацького досвіду

ефективно працюючі реєстри та адміністративні інструменти на платформі з швидкими часом відповіді від сервісів та мінімальним простоєм сприяють позитивному користувацькому досвіду.

1.3. Обсяг тестування продуктивності

Обсяг тестування продуктивності включає усі компоненти реєстру платформи.

2. Тактика продуктивності

Тактика продуктивності — це методики та стратегії оптимізації продуктивності сервісів платформи. Ці тактики адресують різні аспекти продуктивності системи, включаючи час відповіді сервісів, пропускну спроможність, використання ресурсів, масштабованість та стабільність. Нижче наведено список тактик, які використовуються для оптимізації продуктивності платформи.

2.1. Контроль над навантаженням на ресурси

Балансування навантаження

Рівномірний розподіл послуг між декількома вузлами скорочує час відповіді, запобігає перевантаженню та забезпечує оптимальне використання ресурсів.

Кешування

зберігання часто використовуваних даних або раніше обчислених результатів в пам’яті зменшує затримку в майбутніх запитах. Кешування зменшує навантаження і покращує час відповіді при повторних запитах.

Оптимізація коду

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

2.2. Управління ресурсами

Масштабування інфраструктурних сервісів вертикально шляхом додавання додаткових ресурсів до одного сервісу (наприклад, ЦП, пам’ять) або горизонтальне шляхом додавання більшої кількості pod може покращити здатність системи справлятися зі збільшеним навантаженням і трафіком користувачів.

2.3. Моніторинг

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

3. Підхід до тестування продуктивності

Автоматизоване тестування використовується для тестування продуктивності сервісів Платформи. Воно передбачає використання інструментів, сценаріїв і процесів для автоматичного виконання, моніторингу та аналізу тестів продуктивності. Впровадження автоматизованої стратегії тестування продуктивності дає кілька переваг, таких як підвищена ефективність, точність, повторюваність і зменшення людських зусиль. Критичні аспекти впровадження автоматизованого підходу наступні:

  • проектування сценаріїв тестування;

  • визначення та створення тестових даних;

  • вибір інструментів;

  • виконання тестів (кожен реліз) на окремому середовищі;

  • моніторинг та аналітика;

  • звітність.

3.1. Сценарії тестування продуктивності

Як основу для сценаріїв продуктивності реєстрів було взято кінцеві (Е2Е) користувацькі сценарії на рівні API для одного з розроблених реєстрів (детальний опис регламенту наведено в розділі з тестовими даними) та окремі операції GET/POST до бази даних.

Умови та тип запуску мають бути визначені для кожного сценарію перед виконанням.

Умови: час виконання (наприклад, 1 година), кількість користувачів (наприклад, 1500), кількість реєстрів (наприклад, 5)

Кількість користувачів може варіюватися і залежати від базових метрик, зазначених у вимогах до типу реєстру.

Тип запуску: навантаження (очікуване навантаження), стрес (підвищене навантаження)

Нижче наведено список сценаріїв.

3.1.1. Операції GET (читання) до бази даних

Поточний сценарій зосереджений на вивченні продуктивності ізольованих компонентів бази даних реєстру Платформи та дає можливість переконатися, що компонент може витримувати очікувані навантаження. Тест виконує наступні кроки: вхід до кабінету користувача та отримання списку областей та районів з бази даних, оскільки цей запит оперує найбільшим масивом даних і кількістю посилань.

3.1.2. Операції POST (запис) через рівень бізнес-процесів та бази даних

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

Тест виконує наступні кроки:

  • Вхід у кабінет користувача

  • Отримання інформації з інформаційної панелі кабінету

  • Створення нового хімічного фактора в базі даних

3.1.3. E2E сценарій на основі інтеграції та взаємодії користувачів через кабінети користувача та отримувача послуг

Поточний сценарій спрямований на вивчення продуктивності платформи в цілому. Він імітує основні сценарії користувацької взаємодії та їхніх взаємодій: створення лабораторії, зміна її даних, додавання персоналу тощо. Ці сценарії коригуються відповідно до частоти використання користувачами та відповідних затримок для типових операцій. Цей сценарій виконується проти 1 і 5 реєстрів окремими тестами.

Візуалізація кроків E2E-сценаріїв описана нижче:

img 1
Зображення 1. Схема E2E-сценарію на основі частоти використання користувачами


img 2
Зображення 2. Схема API запитів виконання бізнес-процесів для E2E-сценаріїв

3.2. Типи тестування продуктивності

Існує декілька типів тестів продуктивності, кожен з яких фокусується на різних аспектах продуктивності Платформи:

3.2.1. Тестування навантаження

Перевіряє здатність Платформи та реєстрів працювати під очікуваним навантаженням користувачів. Метою є виявлення та аналіз поведінки системи, такої як час відповіді, пропускна здатність і використання ресурсів, коли кілька користувачів одночасно виконують дії над системою, а також виявлення проблем з продуктивністю. Зазвичай використовується у всіх сценаріях, описаних у попередньому розділі.

3.2.2. Стрес тестування

Оцінює продуктивність та стабільність системи в умовах екстремальних користувацьких навантажень. Тестування виявляє точку зламу платформи та реєстрів та допомагає виявити неочікувані проблеми. Зазвичай використовується при автентифікації, читанні/запису даних в базу даних.

3.2.3. Тестування витривалості

Оцінює надійність та міцність платформи та реєстрів шляхом піддавання їх безперервному навантаженню протягом тривалого часу. Цей тип тестування допомагає виявити проблеми, такі як витік пам’яті, вичерпання ресурсів та поступове зниження продуктивності. Зазвичай використовується в усіх сценаріях протягом 8 годин.

3.2.4. Тестування масштабування

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

3.2.5. Тестування стійкості

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

3.3. Тестові дані

3.3.1. Структура регламенту реєстру

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

Модель даних

Модель даних (Завантажити) побудована на основі реального Excel like реєстру Міністерства праці. Для кожної директорії та таблиці автоматично створені API ендпоінти (CRUD) для додавання, зчитування, оновлення та видалення значень. Заповнення форм даними, отриманими з бази даних, виконується з використанням створених Search Condition.

physicalDataModel
Зображення 3. Фізична модель даних
Бізнес-процеси

Бізнес-процеси та модель даних узгоджені між собою. Правила валідації даних на формах бізнес-процесів та в моделі даних не суперечать один одному.

Перелік бізнес-процесів, які використовуються у тестах:

3.3.2. Тестові користувачі

Тестові користувачі створюються у сервісі Keycloak з відповідними атрибутами та ролями перед кожним виконанням тесту.

3.4. Тестові інструменти

Тести на навантаження написані за допомогою інструмента JMeter (стандарт галузі) та Carrier інструменту (https://public.getcarrier.io/), який безпосередньо запускає тести, накопичує результати їх виконання у реальному часі на відповідному Dashboard (звіти) та надає інструменти для їх аналізу.

3.5. Тестове середовище

Для системного тестування продуктивності використовується кластер Openshift у AWS. Створено окремий реєстр (perf-test) та налаштовані всі необхідні моки (імітації) інтеграційних модулів до зовнішніх систем. Тестування проводиться у ізольованому середовищі від зовнішніх систем та не працює з зовнішніми джерелами даних.

3.6. Моніторинг та аналітика

Для успішного аналізу піків і сплесків навантажень використовуються наступні засоби моніторингу та реєстрації:

  • Kibana/ElasticSearch — для пошуку та аналізу логов сервісів Платформи та реєстрів;

  • Grafana/Prometheus на рівні централізованих служб — для моніторингу показників ефективності центральних компонентів;

  • Grafana/Prometheus на рівні сервісів реєстрів — для моніторингу показників навантаження компонентів реєстрів;

  • Jaeger (Kiali) — для відстеження послідовності "запитів/відповідей".

3.7. Звітність

Керівник процесу тестування продуктивності готує звіти після кожної ітерації виконання тестів продуктивності та публікує їх у документації Платформи.

Звіти з тестування продуктивності містять:

  • Метрики та статистику, отриману з інструментів Carrier, Grafana та Jaeger: загальні характеристики сценаріїв, основний графік виконання, графік кількості запитів за одиницю часу, таблиця параметрів за кожним запитом, використання ресурсів (ЦПУ, ОЗП, мережеве використання), таблиця використання ЦПУ за кожним сервісом, таблиця використання ОЗП за кожним сервісом, таблиця використання мережі за кожним сервісом;

  • Список проблем (з назвою запиту, URL, кодом відповіді та повідомленням про помилку) під час виконання тесту.

  • Загальний висновок щодо продуктивності реєстру та його сервісів.

4. Графік тестування продуктивності

Тестування продуктивності проводиться в кожному релізі. Якщо виявлено проблеми, керівник процесу формує відповідні завдання і реалізовує їх у рамках релізних заходів. Після внесення та тестування всіх необхідних змін проводиться новий раунд тестування продуктивності для підтвердження відсутності проблем, пов’язаних з продуктивністю.