Перейти до вмісту
BigTree108

Послуги з тестування продуктивності й навантаження

Послуги з тестування продуктивності й навантаження: навантажувальні тести, стрес-тести, тести на різкі сплески навантаження та тести на витривалість у k6, JMeter, Gatling і Locust, планування потужностей перед запусками та піками продажів, пошук вузьких місць у коді, базах даних та інфраструктурі, продуктивність фронтенду й Core Web Vitals, а також тести продуктивності в CI. Виділені інженери з продуктивності у вашу команду або проєкти тестування продуктивності від початку до кінця.

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

  • Навантажувальне тестування

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

  • Стрес-тести та тести на сплески навантаження

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

  • Тести на витривалість

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

  • Скрипти k6, JMeter, Gatling і Locust

    Grafana k6 на JavaScript, Apache JMeter для наявних тест-планів і протоколів, відмінних від HTTP, Gatling на Java або TypeScript і Locust на Python; скрипти зберігаємо в репозиторії поруч із кодом, який вони тестують.

  • Аналіз вузьких місць

    Результати аналізуємо разом із трейсами, метриками та профілями в Grafana, Datadog, New Relic або Application Insights, тож повільну відповідь вдається простежити до запиту, блокування, пулу потоків чи зовнішнього виклику, які її спричинили, а кожне виправлення перевіряємо повторно під тим самим навантаженням.

  • Планування потужностей для запусків і піків

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

  • Продуктивність фронтенду та Core Web Vitals

    Largest Contentful Paint, Interaction to Next Paint і Cumulative Layout Shift відстежуємо за польовими даними реальних користувачів, причину шукаємо в лабораторних умовах через Lighthouse і WebPageTest, а потім покращуємо показники змінами в зображеннях, скриптах, шрифтах і кешуванні.

  • Тести продуктивності в CI

    Короткі навантажувальні тести з порогами проходження й провалу запускаємо на кожному релізі в GitHub Actions, GitLab CI або Azure Pipelines, більші запуски робимо в Grafana Cloud k6, Azure Load Testing чи BlazeMeter, а кожен запуск порівнюємо з попередньою збіркою, щоб регресію було помічено ще до того, як її відчують користувачі.

  • Тести стійкості та перемикання при відмові

    Інстанси, зони та залежності вимикаємо під навантаженням за допомогою AWS Fault Injection Service, Azure Chaos Studio або Chaos Mesh, щоб перевірити, що перемикання при відмові, повторні спроби та circuit breaker працюють, а відновлення вкладається в цільові показники.

Наші інженери з продуктивності для вашої команди

  • Виділені інженери з продуктивності

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

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

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

  • Постійна співпраця: тестування продуктивності

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

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

Хто працює над вашим проєктом (напрям: тестування продуктивності)

  • Інженери з продуктивності

    Моделі навантаження, скрипти та аналіз

  • SRE-інженери

    Моніторинг, автомасштабування та потужності

  • Бекенд-розробники

    Виправлення в коді, запитах і кешуванні

  • Адміністратори баз даних

    Плани запитів, індекси та ліміти з'єднань

  • Фронтенд-розробники

    Покращення Core Web Vitals

Як ми проводимо тести продуктивності

Кожен тест починається з письмово зафіксованої мети: кількість користувачів або запитів, час відповіді на 95-му чи 99-му перцентилі, допустима частка помилок і вартість. Навантаження моделюється за трафіком продакшну, тестові дані генеруються в обсязі продакшну, а тест виконується на середовищі, розмір якого відповідає продакшну, або на самому продакшні в погоджений проміжок часу.

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

Інші послуги з тестування ПЗ

Тестування ПЗ і QA: огляд

Питання про тестування продуктивності й навантаження

У яких галузях працюють ваші інженери з продуктивності?

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

Чи можете ви проводити навантажувальні тести на продакшні?

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

k6, JMeter чи Gatling?

k6 для більшості нових задач: тести пишуться на JavaScript, запускаються з командного рядка й добре вписуються в пайплайн. JMeter там, де вже є тест-плани або протокол не HTTP, наприклад JDBC, JMS чи чистий TCP. Gatling для команд, що працюють на Java або TypeScript, а Locust для Python-команд. Ми також працюємо з будь-яким інструментом, який уже використовує ваша команда.

Як швидко можуть стати до роботи інженери з продуктивності?

Якщо відповідний інженер з продуктивності вільний, старт залежить лише від вашої співбесіди, NDA і передачі прав на інтелектуальну власність. Інакше ми проводимо пошук, який зазвичай дає профілі кандидатів за два-три тижні, і ніхто не починає роботу, доки ви не скажете «так».

Як найняти фахівців через BigTree108, якщо вам потрібні інженери з продуктивності?

Розкажіть про роботу, рівень і години, які вам потрібні. Ми пропонуємо одну-двох людей з їхніми профілями, ви проводите з ними співбесіду так, як зі своїм власним кандидатом, підписуєте один договір із ТОВ «БІГ ТРІ 108» і отримуєте один рахунок на місяць.

Кому належать результати їхньої роботи?

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

Чекаєте більше трафіку?

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