Як тестувати звіти на навантаження. Сервіс навантажувального тестування loadme. Як визначити розумний показник затримки

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

Тестування навантаження (Англ. Load Testing) - визначення або збір показників продуктивності і часу відгуку програмно-технічної системи або пристрої у відповідь на зовнішній запит з метою встановлення відповідності вимогам, що пред'являються до даної системи (пристрою).

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

Тестування навантаження програмного забезпечення

термін тестування навантаження може бути використаний в різних значеннях в професійному середовищі тестування ПО. У загальному випадку він означає практику моделювання очікуваного використання додатка за допомогою емуляції роботи декількох користувачів одночасно. Таким чином, подібне тестування найбільше підходить для мультіпользовательской систем, частіше - використовують клієнт-серверну архітектуру (наприклад, веб-серверів). Однак і інші типи систем ПО можуть бути протестовані подібним способом. Наприклад, текстовий або графічний редактор можна змусити прочитати дуже великий документ; а фінансовий пакет - згенерувати звіт на основі даних за кілька років. Найбільш адекватно спроектований навантажувальний тест дає більш точні результати.

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

Приклад 1:

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

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

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

В ідеальному випадку в якості критеріїв успішності навантажувального тестування виступають вимоги до продуктивності системи, які формулюються і документуються на стадії розробки функціональних вимог до системи до початку програмування основних архітектурних рішень. Однак часто буває так, що такі вимоги не були чітко сформульовані або були сформульовані зовсім. В цьому випадку перше тестування навантаження буде пробним (exploratory load testing) І ґрунтуватися на розумних припущеннях про очікувану навантаженні і споживанні апаратної частини ресурсів.

Одним з оптимальних підходів у використанні навантажувального тестування для вимірювань продуктивності системи є тестування на стадії ранньої розробки. Тестування навантаження на перших стадіях готовності архітектурного рішення з метою визначити його спроможність називається "Proof-of-Concept" тестуванням.

Основні принципи навантажувального тестування

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

1. Унікальність запитів

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

Ілюстрація різної дисперсії розподілів для часу виконання запитів X і Y.

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

2. Час відгуку системи

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

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

3. Залежність часу відгуку системи від ступеня розподіленості цієї системи.

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

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

4. Розкид часу відгуку системи

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

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

5. Точність відтворення профілів навантаження

Необхідна точність відтворення профілів навантаження тим дорожче, чим більше компонент містить система.

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

Інструментарій для тестування продуктивності

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

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

Існують різні інструменти для виявлення і дослідження проблем в різних вузлах системи. Всі вузли системи можуть бути класифіковані в такий спосіб:

Прикладна програма,
База даних,
Мережа,
Обробка на клієнтській стороні,
Балансування навантаження.

Також слід відзначити появу мережевих Business-to-business (B2B) додатків, що використовують угоду про рівень послуг (або SLA, Service Level Agreement). Наростаюча популярність B2B-додатків привела до того, що все більше додатків переходять на сервіс-орієнтовану архітектуру, в разі якої обмін інформацією відбувається без участі веб-браузерів. Прикладом такої взаємодії може служити бюро туристичних послуг, що запитує інформацію про певний авіарейс між Санкт-Петербургом і Омському, в той час як авіакомпанія зобов'язана надати відповідь протягом 5 секунд. Часто порушення договору про SLA загрожує великим штрафом.

Найбільш популярні інструменти для навантажувального тестування представлені нижче.

ПО	Найменування виробника	Коментарі
OpenSTA	"Open System Testing Architecture"	Вільне програмне забезпечення для навантажувального / стрес тестування, ліцензоване GNU GPL. Використовує розподілену архітектуру додатків, засновану на CORBA. Доступна версія під Windows, хоча є проблеми з сумісністю з Windows Vista. Підтримка припинена в 2007 році.
IBM Rational Performance Tester	IBM	Засноване на середовищі розробки Eclipse ПЗ, що дозволяє створювати навантаження великих обсягів і вимірювати час відгуку для додатків з клієнт-серверною архітектурою. Потребує ліцензування.
JMeter	Відкритий проект Apache Jakarta Project	Заснований на Java багатоплатформовий інструментарій, що дозволяє виробляти навантажувальні тести з використанням JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP з'єднань. Дає можливість створювати велику кількість запитів з різних комп'ютерів і контролювати процес з одного з них.
HP LoadRunner	HP	Інструмент для навантажувального тестування, спочатку розроблений для емуляції роботи великої кількості паралельно працюючих користувачів. Також може бути використаний для unit- або інтеграційного тестування.
SilkPerformer	Micro Focus
Visual Studio Load Test	Microsoft	Visual Studio надає інструмент для тестування продуктивності включаючи load / unit testing
LoadComplete	SmartBear

Основні показники (метрики) продуктивності

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

1. Споживання ресурсів центрального процесора (CPU,%)

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

2. Споживання оперативної пам'яті (Memory usage, Mb)

Метрика, що показує кількість пам'яті, використаної додатком. Використана пам'ять може ділитися на три категорії:

Virtual - обсяг віртуального адресного простору, яке використовує процесор. Цей обсяг не обов'язково має на увазі, використання відповідного дискового простору або оперативної пам'яті. Віртуальний простір звичайно і процес може бути обмежений в можливості завантажувати необхідні бібліотеки.
Private - обсяг адресного простору, зайнятого процесором і не розділяється з іншими процесами.
Working Set - набір сторінок пам'яті, недавно використаних процесом. У разі, коли вільної пам'яті досить, сторінки залишаються в наборі, навіть якщо вони не використовуються. У разі, коли вільної пам'яті залишається мало, використані сторінки видаляються.

При роботі програми пам'ять заповнюється посиланнями на об'єкти, які, в разі невикористання, можуть бути очищені спеціальним автоматичним процесом, званим «збирачем сміття» (англ. Garbage Collector). Час витрачається процесором на очистку пам'яті таким способом може бути значним, в разі, коли процес зайняв всю доступну пам'ять (в Java - так званий «постійний Full GC») або коли процесу виділені великі обсяги пам'яті, що потребують очищення. На час, потрібний для очищення пам'яті, доступ процесу до сторінок виділеної пам'яті може бути заблокований, що може вплинути на кінцевий час обробки цим процесом даних.

3. Споживання мережевих ресурсів

Ця метрика не пов'язана безпосередньо з продуктивністю додатки, проте її показники можуть вказувати на межі продуктивності системи в цілому.

Приклад 3:

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

Тестування навантаження показало, що ефективно сервер може надавати дані тільки 4 користувачам одночасно, так як мультимедіа-потік має бітрейт в 500 кілобіт. Очевидно, що надання цього потоку 5 користувачам одночасно неможливо в силу перевищення пропускної спроможності мережевого каналу, а значить, система не задовольняє заданим вимогам продуктивності, хоча при цьому споживання їй ресурсів процесора і пам'яті може бути невисоким.

4. Робота з дисковою підсистемою (I / O Wait)

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

5. Час виконання запиту (request response time, ms)

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

Див. також

посилання

Майданчик послуг з тестування сайтів та програмного забезпечення (рус.)
Портал фахівців з тестування та забезпечення якості ПЗ (рус.) - Проект присвячений питанням тестування і підвищення якості програмного забезпечення.
База знань тестувальника (рус.) - багтрекер, автоматизоване тестування, тестування навантаження, юзабіліті тестування, спільноти, друковані видання, книги
Автоматизація тестування навантаження (рус.)
Нотатки з тестування навантаження (рус.)

література

Лайза Кріспін, Джанет Грегорі Гнучке тестування: практичне керівництво для тестувальників ПЗ і гнучких команд \u003d Agile Testing: A Practical Guide for Testers and Agile Teams. - М.: "Вільямс", 2010. - 464 с. - (Addison-Wesley Signature Series). - 1000 екз. - ISBN 978-5-8459-1625-9

Wikimedia Foundation. 2010 року.

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

Все йде за планом

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

Навантажувальний (Load-testing) - визначається працездатність системи
при деякій суворо заданої заздалегідь (планованої, робочої) навантаженні.
Стійкості (Stress) - застосовується для перевірки параметрів системи
в анормальних та екстремальних умовах, основне завдання під час цього тесту -
спробувати порушити роботу системи. Дозволяє визначити мінімально
необхідні величини системних ресурсів для роботи програми, оцінити
граничні можливості системи і фактори, що обмежують ці можливості.
Також визначається здатність системи до збереження цілісності даних при
виникненні позаштатних аварійних ситуацій.
Продуктивності (Performance) - комплексна перевірка, що включає
попередні два тести, призначена для оцінки всіх показників системи.

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

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

скільки відвідувачів планується приймати в середньому, в піковому навантаженні,
час пікового навантаження;
можуть декілька користувачів мати один і той же IP-адресу і / або
Логін: Пароль;
середня кількість сторінок, що переглядаються одним користувачем, чи є
відмінності в поведінці між зареєстрованими і анонімними користувачами,
кількісне співвідношення між такими користувачами, відвідувані сторінки і
час знаходження користувача на вузлі;
наявність динамічних сторінок і сторінок, змінюваних протягом певного
періоду, і як часто це відбувається;
задіюється чи електронна пошта, Наприклад, для підтвердження повноважень
користувача;
яка ще додаткова інформація використовується для перевірки статусу
користувача (cookies);
чи потрібне підтвердження повноважень користувача сторонньою організацією
або віддаленим сервером (наприклад, номер кредитної картки), і чи буде
представлена \u200b\u200bінформація для тестування;
доступна пропускна здатність каналу, середня його ширина для одного
користувача;
чи може робота декількох користувачів викликати колізію;
чи використовується захищене HTTPS-з'єднання;
чи використовується Java-аплети, потокове медіа, спеціальні плагіни, що
потрібно з клієнтської сторони для їх підтримки;
чи використовується кешування сторінок;
планові технічні заходи, які можуть вплинути на роботу
сервера, і час їх проведення (синхронізація, архівування та ін.).

Будь-який з цих параметрів може вплинути на кінцевий результат. Не обов'язково
всі перевірки включати в один тест, можна розбити спочатку задачу на підзадачі.
Наприклад, перевірка базової системи (Сервери: веб, додатків, бази даних) і
перевірка окремих модулів (сервлети, скрипти та ін., наприклад, перевірка
аутентифікації при великій кількості користувачів). В результаті при
тестуванні видаються графіки трьох видів: лінійний, нелінійний і насичення. В
першому випадку при зростанні навантаження час відгуку (тобто обробки) залишається
постійним. При подальшому збільшенні навантаження час відгуку також збільшується
(Майже лінійно), і, нарешті, настає ситуація, подібна DOS-атаки, коли час
відгуку нескінченно збільшується. Тепер, коли план дій готовий, переходимо до
короткому огляду утиліт, які допоможуть його втілити. Почнемо з безкоштовних.

Open Systems Testing Architecture

OpenSTA (Www.opensta.org)
- більше ніж додаток для тестів, це відкрита архітектура, проектована
навколо відкритих стандартів. Проект створений в 2001 році групою компаній CYRANO,
яка підтримувала комерційну версію продукту, але CYRANO розпався, і зараз
OpenSTA поширюється як додаток з відкритим кодом під ліцензією
GNU GPL, працює в Windows NT 4.0SP5 / 2000 / XP. Для роботи вимагає Microsoft Data
Access Components (MDAC), який можна завантажити сайту корпорації.

Поточний інструментарій дозволяє провести навантажувальний випробування HTTP / HTTPS
сервісів, хоча його архітектура здатна на більше. OpenSTA дозволяє
створювати тестові сценарії на спеціалізованій мові SCL (Script Control
Language). Для спрощення створення і редагування сценаріїв використовується
спеціальний інструмент Script Modeler. Вибираємо Tools - Canonicalize URL,
запуститься веб-браузер. Просто ходимо по сайту, збираючи посилання, які будуть
збережені в скрипт. Всі параметри запиту піддаються редагуванню, можлива
підстановка змінних. Структура тесту і заголовки будуть виводитися у вкладках
в панелі зліва. Тести зручно об'єднувати в набори. Налаштування проксі задаються в
самому скрипті, тому можна вказати кілька серверів. реалізована можливість
організації розподіленого тестування, що підвищує реалістичність, або коли
з одного комп'ютера не виходить навантажити потужний сервер. Кожна з машин такої
системи може виконувати свою групу завдань, а repository host здійснює збір
і зберігання результатів. Після установки на кожній тестирующей системі
запускається сервер імен, робота якого обов'язкова. підтримується
аутентифікація користувачів на веб-ресурсі і встановлення з'єднань по
протоколу SSL. Параметри роботи навантажується системи можна контролювати з
допомогою SNMP і засобів Windows NT. Результати тестування, що включають час
відгуків, кількість переданих байт в секунду, коди відповіді для кожного запиту
і кількість помилок виводяться у вигляді таблиць і графіків. Використання великого
числа фільтрів дозволяє відібрати необхідні результати. результат можна
експортувати в CSV-файл. Можливості щодо виведення звітів дещо обмежені,
але по посиланнях на сайті можна знайти скрипти і плагіни, що спрощують, в тому числі,
аналіз отриманої інформації.

Apache JMeter

Apache JMeter (Jakarta.apache.org/jmeter)
є Java-додатком з відкритим кодом, призначений для навантажувального
тестування не тільки веб-додатків і їх окремих компонентів (Скрипти,
сервлети, Java об'єкти і ін.), але також FTP-серверів, баз даних (з
використанням JDBC) і мережі. Функціональність розширюється за допомогою плагінів.
Підтримується SSL (через Java Secure Sockets Extension). можливе проведення
тестів як з використанням графічного інтерфейсу, так і з командного рядка.
Використання Java на увазі кроссплатформенность, тому JMeter
впевнено працює в різних * nix-системах, в Windows від 98 і деяких інших
ОС. Поширюється під Apache License.

В JMeter передбачені механізми авторизації віртуальних
користувачів, підтримуються призначені для користувача сеанси, шаблони, кешування і
наступний offline аналіз результатів тесту, функції дозволяють сформувати
наступний запит, грунтуючись на відповіді сервера на попередній. Є можливість
проводити розподілені тести. У цьому випадку один з комп'ютерів є
сервером (bin / jmeter-server.bat), який управляє клієнтами і збирає
підсумкову інформацію.

Для роботи досить запустити ApacheJMeter.jar або в консолі jmeter.bat
(Windows) або jmeter.sh (* nix).

JMeter має вбудований проксі-сервер, який призначений для запису
сесій, але можна використовувати і зовнішній. Перед початком тестування необхідно
скласти тестовий план, що описує серію завдань, які необхідно виконати
JMeter. Він повинен містити одну або кілька груп потоків (Thread
Groups) і інші елементи:

Логічні контролери (Logic controllers);
Типові контролери (Sample generating controllers);
Слухачі (Listeners);
Таймери (Timers);
Відповідності (Assertions);
Конфігураційні елементи (Configuration elements).

Насамперед додаємо групу потоків (Edit - Add - Thread Group). В її
налаштуваннях вказуємо назву, кількість запускаються потоків, тобто
віртуальних користувачів (Number of threads), час затримки між запуском
потоків (Ramp-Up Period), кількість циклів виконання завдання (Loop Count),
тут же можна визначити виконання завдання за розкладом (Sheduler). далі,
клацаючи в створену групу, необхідно додати зразок запиту (Sampler), вибравши
його зі списку. Для навантажувального тестування або перевірки працездатності
сервера досить вибрати HTTP Request (Add -Sampler - HTTP Request). тут
вказуємо назву, IP-адреса і порт веб-сервера, протокол, метод передачі даних
(GET, POST), параметри переадресації, передачу файлів на сервер. налаштовуємо і
тиснемо на Run. Висновок результату здійснюється за допомогою Listeners, кожен
по-своєму виводить результат. Наприклад, Aggregate Graph виводить сумарні
результати тесту у вигляді таблиці і графіка.

Безкоштовні продукти, на жаль, закінчилися, тепер парочка комерційних рішень.

WAPT - Web Application Testing

WAPT (Www.loadtestingtool.com)
дозволяє випробувати стійкість веб-сайту та інших додатків, що використовують
веб-інтерфейс, до реальних навантажень. Розробляється новосибірської компанією
SoftLogica LLC. Це одна з найпростіших у використанні програм огляду. для
проведення простого тесту навіть не потрібно заглядати в документацію, інтерфейс
простий, але не локалізований. Працює під управлінням Windows від 98, підтримується
і Vista. Для перевірки WAPT може створювати безліч віртуальних
користувачів, кожен з індивідуальними параметрами. підтримується кілька
видів аутентифікації і куки. Сценарій дозволяє змінювати затримки між
запитами і динамічно генерувати деякі випробувальні параметри,
максимально імітуючи таким чином поведінку реальних користувачів. У запит
можуть бути підставлені різні варіанти HTTP-заголовка, в налаштуваннях можна
вказати кодування сторінок. Параметри User-Agent, X-Forwarded-For, IP вказуються
в настройках сценарію. Значення параметрів запиту можуть бути розраховані
декількома способами, в тому числі, визначені відповіддю сервера на попередній
запит, використовуючи змінні і функції. Підтримується робота по захищеному
протоколу HTTPS (і всі типи проксі-серверів). Створені сценарії, які зберігаються в
файлі XML-формату, можна використовувати повторно. Крім стандартних Performance і
Stress, в списку присутні кілька інших тестів, що дозволяють визначити
максимальну кількість користувачів і тестувати сервер під навантаженням в
Протягом довгого періоду.

Для проведення тесту необхідно вибрати New - Scenario, в результаті
запуститься майстер створення тесту. На першому кроці вказується тип тесту і далі в
кожному вікні заповнюються параметри майбутнього тесту. Тут можна вказати
фіксована кількість віртуальних користувачів, або ступеневу збільшення
із зазначенням мінімального і максимального числа і тимчасового інтервалу, виставити
таймер проведення тесту. На наступному кроці задається час між кліками (think
time), швидкість з'єднання, вказується діапазон IP-адрес, який буде
використаний віртуальними користувачами. Натискання на IP Adress List дозволить
скласти список таких адрес. Також виставляється HTTP-параметр User-Agent і
включається емуляція проксі. Якщо потрібно, щоб віртуальні користувачі мали
індивідуальні настройки, На наступному кроці майстра для кожного з них
необхідно створити свій профіль, натиснувши New або завантаживши збережений. В наступному
вікні програми необхідно виставити параметри профілів.

Після натискання на кнопку Готово сценарій зберігається. Тепер, щоб вказати на
об'єкт тестування, створюємо профіль New - Profile і заповнюємо всі параметри на
вкладках. Тут же доступні для редагування деякі параметри, що задаються
раннє за допомогою майстра. Також вказується завантаження малюнків віртуальним
користувачем, параметри аутентифікації, використання Cookies і інші.
На вкладці Recorder вказуємо адресу сайту, доступність якого можна тут же
перевірити, натиснувши Go. Одночасно буде запропоновано запуск Recorder, який
відстежуватиме відвідані сторінки і записувати URI (вони будуть виводитися в
панелі ліворуч). Коли вся інформація зібрана, натискаємо Run Test. докладні звіти
в формі графіка виводяться по ходу проведення тесту, після закінчення буде
сформована HTML-сторінка. В результаті можна отримати інформацію про час
відповіді сервера зі зростанням навантаження, за кількістю помилок, переданих та
прийнятих байт і т.д.

NeoLoad

NeoLoad (Www.neotys.com)
- ще одна система, що дозволяє провести тестування навантаження
веб-додатків. Написана на Java, працює на комп'ютерах, що працюють під
управлінням Windows NT / 2000 / XP, Linux і Solaris. У звіті можна отримати
детальну інформацію по кожному завантаженому файлі. NeoLoad вельми зручний для
оцінки роботи окремих компонентів (AJAX, PHP, ASP, CGI, Flash, аплетів і
пр.). Можлива установка часу затримки між запитами (thinktime) глобально
і індивідуально для кожної сторінки. Тестування проводиться як з
використанням дуже зручною графічної оболонки, так і за допомогою командного
рядки (використовуючи заздалегідь підготовлений XML-файл). Підтримує роботу з
протоколом HTTPS, з HTTP і HTTPS проксі, basic веб-аутентифікацію і cookies,
автоматично визначаючи дані під час запису сценарію, і потім програє у
час тесту. Для роботи з різними профілями для реєстрації користувачів
можуть бути використані змінні. При проведенні тесту можна задіяти
додаткові монітори (SNMP, WebLogic, WebSphere, RSTAT і Windows, Linux,
Solaris), що дозволяють контролювати і параметри системи, на якій працює
веб-сервер.

За допомогою NeoLoad можна проводити і розподілені тести. Один з
комп'ютерів є контролером, на інші встановлюються генератори
навантаження (loadGenerator). Контролер розподіляє навантаження між loadGenerator і
збирає статистику.

Дуже зручно реалізована робота з віртуальними користувачами. користувачі
мають індивідуальні настройки, потім вони об'єднуються в Populations (повинна
бути створена як мінімум одна Populations), в Populations можна задати загальне
поведінку (наприклад, 40% користувачів популяції відвідують динамічні ресурси,
20% читають новини). Віртуальні користувачі можуть мати індивідуальний
IP-адреса, смугу пропускання і свій сценарій тесту.

Сценарій майбутнього тесту створити дуже просто. Запускаємо програму (при
першому запуску буде потрібно ввести реєстраційний ключ, 30-денна версія після
реєстрації буде надіслано поштою), вибираємо New Project, вводимо назву
проекту. Після цього буде показана невелика підказка з приводу подальших
дій, натискання Start Recording запустить веб-браузер, всі переміщення будуть
записані. Після закінчення натискаємо Stop Recording або закриваємо браузер.
Запускається майстер, який допоможе створити віртуальних користувачів і
справить автоматичний пошук динамічних параметрів в записаних сторінках,
виставить середнє значення thinktime. Компоненти сторінки (HTML, images, CSS)
зберігаються окремо. Для отримання результату потрібно пройти три етапи:

Design - настройка проекту, тут три вкладки. У Repository вказуються
веб-сторінки і параметри запитів, в Virtual User створюються віртуальні
користувачі, вказуються URL, які вони повинні "відвідати", і додаткові
умови з лівої вкладки поля Actions. У Populations - завдання кожної з груп
користувачів. У Actions можуть бути обрані наступні дії: Delay
(Установка затримки), Loop (повтор запиту), While (цикл), If ... Then ... Else
(Умова), Container і Random Container (групові дії), Try ... Catch
(Обробка помилок), Stop virtual user (зупинка роботи віртуального
користувача).
Runtime - вказуються параметри тесту, проводиться тест. Тут же в
окремих вкладках по ходу проведення тесту виводиться статистика.
Results - відповідає за виведення різної статистики у вигляді таблиць і графіків.

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

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

Продукти від Microsoft

Корпорація Microsoft пропонує цілих два продукти, що дозволяють
протестувати веб-сервер під навантаженням. це Microsoft Application Stress
Tool і Web Capacity Analysis Tool. Перший поширюється як
окремий продукт і має графічний інтерфейс. Другий входить до складу
комплекту інструментів Internet Information Services 6.0 Resource Kit Tools,
працює з командного рядка. MAST більш наочний, в створенні тесту
допоможе простий майстер створення тестів, можлива робота з cookies, регулювання
навантаження за різними URL. Сценарій тестування може бути створений вручну або
записаний за допомогою веб-браузера та при необхідності відредагований. В WAST
рівень навантаження (stress level) регулюється шляхом завдання кількості ниток,
здійснюють запити до сервера, а число віртуальних користувачів
розраховується як добуток кількості ниток на число гнізд, відкритих кожної з
ниток. Після закінчення тесту отримуємо простий звіт в текстовій формі, в якому
дана інформація по числу оброблюваних запитів в одиницю часу, середнього
часу затримки, швидкості передачі даних на сервер і з сервера, кількістю
помилок і т.д. Звіт можна експортувати в CSV-файл. Ніяких можливостей по
статистичній обробці не передбачено, тобто з його допомогою можна тільки
оцінити роботу за певних умов.

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

Навіщо проводиться тестування навантаження:

Перевірка і оптимізація конфігурації обладнання, віртуальних машин, серверного програмного забезпечення;
оцінка максимальної продуктивності, Яку здатний витримувати проект з типовими сценаріями навантаження на доступних ресурсах;
Вплив модулів проекту на продуктивність, сценарії обробки пікового навантаження;
Оцінка стабільності при максимальних навантаженнях при проведенні 24-годинних тестів з урахуванням зовнішніх чинників (обсяги імпорту, резервне копіювання і т.п.);
Виявлення обмежень конфігурації, визначення методів подальшого масштабування і оптимізації.

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

Apache HTTP server benchmarking tool

Безкоштовний

Офіційний сайт

Самий часто використовуваний, т.к входить до складу Apache.

Ab: //] hostname [: port] / path

де основні необхідні options:

C concurrency - кількість одночасних запитів до сервера (за замовчуванням 1);
-n requests - загальна кількість запитів (за замовчуванням 1).

В результаті команди отримуємо такий звіт:

Concurrency Level: 10 Time taken for tests: 0.984 seconds Complete requests: 100 Failed requests: 0 Write errors: 0 Total transferred: 3725507 bytes HTML transferred: 3664100 bytes Requests per second: 101.60 [# / sec] (mean) Time per request: 98.424 (mean) Time per request: 9.842 (mean, across all concurrent requests) Transfer rate: 3696.43 received Connection Times (ms) min mean [+/- sd] median max Connect 1 2 3.6 1 23 Processing: 63 94 21.5 90 173 Waiting: 57 89 21.6 84 166 Total: 64 96 21.5 92 174

плюси:

Є скрізь, де є Apache;
Не потребує ніякої додаткової настройки;
Дуже простий інструмент.

мінуси:

Дуже простий інструмент;
Тестує тільки продуктивність веб-сервера: опитує тільки один URL, не підтримує сценарії навантаження, неможливо імітувати призначену для користувача навантаження і оцінити працездатність проекту з усіх боків - як з точки зору інфраструктури, так і з точки зору розробки.

Joe Dog Siege

Безкоштовний

Офіційний сайт .

трохи складніше ab і необхідні завдання виконує набагато краще.

У файлі-сценарії задаються URL-и та запити тестування. Якщо сценарій великий за обсягом, то можна винести все запити в окремий файл і в команді вказати цей файл при тестуванні:

# Cat urls.txt # URLS file for siege # - http://www.bitrix24.ru/ http://www.bitrix24.ru/support/forum/forum1/topic3469/?PAGEN_1\u003d2 http: // www .bitrix24.ru / register / reg.php POST domain \u003d test & login \u003d login http://www.bitrix24.ru/search/ POST

У команді вказується кількість користувачів -з, кількість повторень -r і затримку між хітами -d.

Результат можна виводити в log-файл або відразу в консоль в режимі реального часу:

HTTP / 1.1 200 0.44 secs: 12090 bytes \u003d\u003d\u003e GET / HTTP / 1.1 200 0.85 secs: 29316 bytes \u003d\u003d\u003e GET / support / forum / forum1 / HTTP / 1.1 200 0.85 secs: 29635 bytes \u003d\u003d\u003e GET / support / forum / forum1 / HTTP / 1.1 200 0.34 secs: 12087 bytes \u003d\u003d\u003e GET / [...] done. Transactions: 100 hits Availability: 100.00% Elapsed time: 12.66 secs Data transferred: 1.99 MB Response time: 0.64 secs Transaction rate: 7.90 trans / sec Throughput: 0.16 MB / sec Concurrency: 5.02 Successful transactions: 100 Failed transactions: 0 Longest transaction: 1.06 Shortest transaction: 0.31

Також можна взяти з access-log веб-сервера URL-и, по яких ходили реальні користувачі і емулювати навантаження реальних користувачів.

плюси:

Багатопотоковий;
Можна задавати як кількість запитів, так і тривалість (час) тестування - тобто можна емулювати призначену для користувача навантаження;
Підтримує найпростіші сценарії

мінуси:

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

Apache JMeter

Безкоштовний

Офіційний сайт

Основні можливості:

Написаний на Java;
HTTP, HTTPS, SOAP, Database via JDBC, LDAP, SMTP (S), POP3 (S), IMAP (S);
Консоль і GUI;
Розподілене тестування;
План тестування - XML-файл;
Може обробляти лог веб-сервера як план тестування;
Візуалізація результатів в GUI.

Результати виводяться в графічному вигляді:

плюси:

Багатоплатформовий, т.к написаний на Java;
Дуже гнучкий, використовується багато протоколів, не тільки веб-сервер, але і бази;
Управляється через консоль і gui інтерфейс;
Використання безпосередньо логів веб-сервера Apache і Nginx в якості сценарію c можливістю варіювання навантаження за цими профілями;
Досить зручний і потужний інструмент.

мінуси:

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

Tsung

Безкоштовний

Офіційний сайт

Основні можливості:

Написаний на Erlang;
HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP, Jabber / XMPP;
Консоль (GUI через сторонній плагін);
Розподілене тестування (мільйони користувачів);
Фази тестування;
План тестування - XML;
Запис плану за допомогою Tsung recorder'а;
Моніторинг тестованих серверів (Erlang, munin, SNMP);
Інструменти для генерації статистики і графіків з логів роботи.

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

плюси:

Т.к на писаний на Erlang, то добре масштабується, залежить від виділених ресурсів;
Може виконувати роль розподіленої системи, на великій кількості машин;
Велика кількість тестованих систем - не тільки веб-сервери і БД, а й, наприклад, XMPP-сервер: може відправляти повідомлення, тести з авторизацією;
Управління через консоль, але, завдяки підтримці плагінів, можна управляти і за допомогою стороннього плагіна з gui-інтерфейсом;
Наявність в комплекті інструменту Tsung Recorder - свого роду, proxy-сервер, через який можна ходити по тестируемому сайту і записувати відразу як профіль навантаження;
Генерація різних графіків тестування за допомогою скриптів.

мінуси:

Немає gui-інтерфейсу;
Тільки * nix системи.

WAPT

платний

Офіційний сайт

Основні можливості:

Windows
Платний (є тріал на 30 днів / 20 віртуальних користувачів);
Запис плану тестування з десктопних і мобільних браузерів;
Залежності в планах тестування (наступний URL в залежності від відповіді сервера);
Імітації реальних користувачів (затримки між сполуками, обмеження швидкості з'єднань).

Звіт можна вивести як таблицею, так і графіком.

Далеко не кожен користувач сучасної комп'ютерної системи в повсякденній роботі стикається з поняттям «тестування навантаження». В основному воно знайоме веб-розробникам і всім тим, хто використовує ресурсомісткі програми. Проте іноді знання в цьому питанні можуть стати в нагоді і рядовим користувачам. Спробуємо розібратися, навіщо все це потрібно.

Навантажувальний і цілі

Перш за все, варто чітко розмежувати види таких тестів. Умовно їх можна поділити на два класи: перевірка комп'ютерного «заліза» при максимально можливої \u200b\u200bабо надмірному навантаженні на кожен компонент і (веб-сайтів з елементами прогнозування, окремо взятих програм і т. Д.).

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

Програми для навантажувального тестування та їх завдання

Як бачимо, взаємозв'язок тут дуже сильна. І якщо говорити про «залізі», система тестування навантаження з використанням спеціальних утиліт дозволяє досить точно виявити потенційні неполадки при роботі, так би мовити, в найпростіший. Сучасні комп'ютерні ігри з їх вимогами можуть запросто навантажити систему до такого стану, що вона взагалі перестане працювати. Тому, перш ніж встановлювати таке ПО на комп'ютер, можна провести серію тестів, щоб визначити, чи зможе начинка «тягнути» гру. За результатами і приймається рішення про встановлення програми. В принципі, те ж саме стосується і додатків, які передбачають проведення складних математичних розрахунків, і проектних робіт, оскільки навантаження на той же процесор або оперативну пам'ять в порівнянні зі звичайним станом системи може бути перевищена в рази.

Що ж стосується другого класу, тестування сайту і сервера може виступати як якесь універсальне засіб прогнозування їх поведінки в умовах реального функціонування. Наприклад, це може бути емуляція одночасного запиту доступу великого числа користувачів. Як відомо, за таким принципом діють DDoS-атаки, коли сервер або сайт не встигає обробляти занадто велика кількість звернень. Тестування навантаження сервера або сайту буде розглянуто докладніше трохи пізніше. А поки займемося комп'ютерним «залізом». Це стосується не тільки домашніх або робочих терміналів, але і реальних фізичних серверних систем.

тест процесора

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

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

При використанні утиліти для початку рекомендується закрити всі активні програми і відключити автоматичний (сну), щоб комп'ютер ненароком не відключився в процесі перевірки. Тепер потрібно змоделювати процесору найжорсткіші умови (а програма може це зробити, як ніяка інша, дійсно ставлячи чіпи в найважчі умови). Сам тест активується з меню опцій, де вибирається розділ Torture Test. Там будуть вказані види операцій, що проводяться. Найцікавішими тут представляються тести Blend (одночасна навантаження і на процесор, і на «оперативку»), а також Small FFT і Large FFT (збільшення навантаження на процесор за рахунок вивантаження оперативної пам'яті).

Як визначити, що тестування навантаження пройшло успішно? єдиної думки тут немає, але вважається, що якщо протягом хоча б 4 годин помилок або збоїв в роботі чіпа не спостерігалося, цей компонент досить стійкий до надмірних навантажень. Але буває і таке, що збої можуть з'явитися набагато пізніше, тому, якщо у вас є неабиякий запас часу, краще збільшити період тестування до 24 годин (помилки можуть з'явитися і через півдня роботи).

Перевірка роботи оперативної пам'яті

Не менш важливим є і тестування навантаження «оперативки», яка виконує функції так званої другої скрипки. Для цього найкраще підійде додаток Memtest86 +, яке на сьогоднішній день є найкращим.

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

Визначення поведінки графічного адаптера

З графікою теж варто провести тест, оскільки відеоадаптери при надмірному навантаженні часто є причиною комп'ютерних збоїв. Ідеальним інструментом тут стане програма FurMark.

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

Крім того, можна використовувати і спеціальні утиліти, розроблені під конкретні гри. Наприклад, дуже добре підійдуть тестові додатки типу Alien vs Predator, S.T.A.L.K.E.R. або ще щось в цьому роді. Як правило, поширюються вони абсолютно безкоштовно, а з їх допомогою можна точно встановити, як буде вести себе система після установки оригінального ігрового пакета.

Для чого потрібно тестування серверів і сайтів

Тепер кілька слів про те, що являє собою тестування сайту і веб-сервера. Про один аспект (DDoS-атаки) вже було сказано. Зараз подивимося на це питання з іншого боку.

Самі тести такого типу в деякій мірі можна віднести навіть до маркетингових інструментів по прогнозуванню поведінки користувачів. Так, наприклад, можна змоделювати ситуацію поведінки певної кількості (максимального / пікового) людей при вході на сайт, дізнатися, скільки сторінок може проглядатися, чи буде задіяна електронна пошта, наприклад, в процесі замовлення товару, як інформація може використовуватися для ідентифікації відвідувачів, дозволить чи можна надати одночасний доступ до сайту користувачам в певний момент часу, чи буде популярним підтвердження користувальницьких повноважень третьою особою (наприклад, при введенні номера банківської карти), Наскільки ефективним виявиться впровадження Java-аплетів або використання захищеного з'єднання https і т. Д.

Питання тесту веб-серверів (програмного забезпечення) і створюваних Інтернет-ресурсів

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

В даному випадку (і для сайту, і для веб-сервера) багато хто радить використовувати найпотужніший пакет під назвою OpenSTA (System Architecture Test), який дозволяє не тільки провести перевірку, а й розбити завдання на складові для кожного окремо взятого елемента структури з використанням інструменту створення і моделювання скриптів Script Modeler. Примітно, що після створення такої моделі можна перевірити навіть з'єднання по протоколу SSL (обов'язково повинен бути запущений так званий сервер імен). Крім того, результати можна зберігати в розділі Repository Host, а тести об'єднувати в відповідні групи.

Що в підсумку?

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

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

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

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

Основні поняття

Для початку потрібно ознайомитися з базовими термінами і поняттями.

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

Основи навантажувального тестування

Тестування навантаження - це технологія вимірювання продуктивності сервера, яка полягає у відправці імітованого HTTP-трафіку на сервер. Це дозволяє знайти відповіді на такі питання:

Чи достатньо у сервера ресурсів (пам'яті, CPU і т. П.), Щоб обробити очікуваний трафік?
Чи достатньо швидко реагує сервер, щоб забезпечити хороший користувальницький досвід?
Чи ефективно працює додаток?
Чи потрібно сервера вертикальне чи горизонтальне масштабування?
Чи є особливо ресурсовитратні сторінки або виклики API?

Тестування навантаження виконується шляхом запуску спеціального програмного забезпечення на одному комп'ютері (або в кластері машин). Це ПО генерує велику кількість запитів і відправляє їх на веб-сервер на другому комп'ютері (або в іншу інфраструктуру). Існує багато таких інструментів, пізніше ми розглянемо деякі з них. На даний момент зосередимося на загальних термінах, які будуть актуальні незалежно від того, який засіб для навантажувального тестування ви виберете. Звичайне програмне забезпечення для навантажувального тестування використовується для визначення максимальної кількості запитів в секунду, яке може обробляти сервер. Для цього на сервер відправляється якомога велика кількість запитів; потім потрібно перевірити, скільки з них сервер зміг обробити успішно.

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

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

Як визначити розумний показник затримки?

Час завантаження веб-сайту в діапазоні 2-5 секунд - звичайна справа, але частина часу, пов'язана з затримкою веб-сервера, зазвичай становить близько 50-200 мілісекунд. Ідеальний показник затримки індивідуальний для кожного сайту. Він залежить від великої кількості факторів (аудиторії, ринку, цілей сайту, наявності призначеного для користувача інтерфейсу або API і т. Д.). Майте на увазі: більшість досліджень показують, що в продуктивності враховується кожен маленький біт швидкості, і навіть зовсім непомітні поліпшення призводять до поліпшення результатів в цілому.

Планування навантажувального тестування

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

1: Моніторинг ресурсів

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

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

Якщо у вас вже є система моніторингу типу Prometheus, Graphite або CollectD, ви зможете зібрати всі необхідні дані.

Читайте також:

Якщо такої системи немає, встановіть з'єднання з веб-сервера і використовуйте наступні інструменти командного рядка для моніторингу в реальному часі.

Для моніторингу доступної пам'яті використовуйте команду free. У комбінації з командою watch дані будуть оновлюватися кожні 2 секунди.

Прапор -h виводить числа в легкому для читання форматі.

total used free shared buffers cached
Mem: 489M 261M 228M 352K 7.5M 213M
- / + buffers / cache: 39M 450M
Swap: 0B 0B 0B

Виділене число у висновку являє вільну пам'ять після вирахування буфера і кеша. нові версії free виводять інші результати:

Total used free shared buff / cache available
Mem: 488M 182M 34M 14M 271M 260M
Swap: 0B 0B 0B

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

Для моніторингу використання CPU в командному рядку є утиліта mpstat, яка виводить кількість вільних ресурсів CPU. За замовчуванням утиліта mpstat не встановлена \u200b\u200bв Ubuntu. Ви можете встановити її за допомогою наступної команди:

sudo apt-get install sysstat

При запуску mpstat потрібно задати інтервал поновлення даних в секундах:

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

Linux 4.4.0-66-generic (example-server) 08/21/2017 _x86_64_ (4 CPU)
8:06:26 PM CPU% usr% nice% sys% iowait% irq% soft% steal% guest% gnice% idle
8:06:28 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
8:06:30 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

Стовпець% idle показує, який відсоток ресурсів ЦП не використовується. Завантаження процесора часто розділяється на різні категорії (user CPU і system CPU).

2: Визначення максимальної швидкості відгуку

Як говорилося раніше, більшість програм навантажувального тестування особливо добре підходять для пошуку максимальної швидкості відповіді веб-сервера. Як правило, при цьому потрібно вказати тільки конкурентність і тривалість тестування.

Конкурентність - це показник, який відображає кількість паралельних підключень, яке може обробляти сервер. Значення за замовчуванням 100 підходить в більшості випадків, але ви можете вибрати індивідуальне значення. Для цього потрібно перевірити MaxClients, MaxThreads сервера і інші подібні параметри.

Також вам потрібно буде вибрати URL-адресу для тестування. Якщо ваше програмне забезпечення може обробляти тільки один URL за один раз, варто виконати кілька тестів для різних URL-адрес, так як вимоги до обробки можуть сильно відрізнятися в залежності від сторінки. Наприклад, вимоги до завантаження домашньої сторінки сайту і сторінки продукту різні.

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

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

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

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

Потім потрібно повторити тестування, щоб отримати додаткову інформацію про те, як працює сервер на межі ресурсів.

3: Визначення максимальної пропускної спроможності

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

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

Візьміть максимальну швидкість запитів, яку ви визначили на попередньому етапі, і розділіть її на 2. Запуск ще один тест з новими даними і зверніть увагу на час відповіді. Чи знаходиться показник в прийнятному діапазоні?

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

Інструменти для навантажувального тестування

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

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

інструмент ab

(Або ApacheBench) - це простий однопотоковий інструмент командного рядка для тестування HTTP-серверів. Спочатку він розроблявся як частина HTTP-сервера Apache, але його можна використовувати для тестування будь-якого HTTP- або HTTPS-сервера.

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

Базовий виклик команди ab виглядає наступним чином:

ab -n 1000 -c 100 http://example.com/

Прапор -n задає кількість запитів. Прапор -з задає конкурентність. Потім потрібно вказати URL, який потрібно протестувати. Висновок (витяг з якого наведено нижче) вказує кількість запитів в секунду, час запиту і список процентилей часу відповіді:

. . .
Requests per second: 734.76 [# / sec] (mean)

Time per request: 136.098 (mean)
Time per request: 1.361 (mean, across all concurrent requests)
Transfer rate: 60645.11 received
Percentage of the requests served within a certain time (ms)
50% 133

66% 135

75% 137

80% 139

90% 145

95% 149

98% 150

99% 151

100% 189 (longest request)

JMeter

JMeter - це потужне і багатофункціональне додаток для навантажувального і функціонального тестування від Apache Software Foundation. Функціональне тестування - це перевірка виведення додатки.

JMeter пропонує графічний інтерфейс Java для настройки тестових планів.

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

JMeter може виводити інформацію про процентилями в звітах HTML і інших форматах.

Siege

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

siege -c 100 -t 30s http://example.com/

Прапор -з вказує конкурентність. Прапор -t визначає тривалість тестування (в даному випадку - 30 секунд). Siege виводить середній час відгуку і швидкість запиту:

. . .
Transactions: 5810 hits
Availability: 100.00%
Elapsed time: 29.47 secs
Data transferred: 135.13 MB
Response time: 0.01 secs

Transaction rate: 197.15 trans / sec
Throughput: 4.59 MB / sec
Concurrency: 2.23
. . .

Siege не надає процентилей для статистики затримок.

Locust

Locust - це інструмент для навантажувального тестування на основі Python, Який надає веб-інтерфейс для моніторингу результатів в реальному часі.

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

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

Locust може надати докладну статистику в CSV-файлах, які можна завантажити.

інструмент wrk2

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

wrk2 викликається командою wrk:

wrk -t4 -c100 -d30s -R100 --latency http://example.com/

Параметр -t визначає кількість потоків (в даному випадку їх 4, тут потрібно використовувати кількість процесорних ядер вашого сервера). Параметр -c вказує кількість одночасних запитів (тут 100). Прапор -d визначає тривалість тестування (30 секунд). Прапор -R вказує частоту запитів в секунду (100). Докладний висновок затримки надасть прапор -latency.

. . .
Latency Distribution (HdrHistogram - Recorded Latency)
50.000% 5.79ms
75.000% 7.58ms
90.000% 10.19ms
99.000% 29.30ms
99.900% 30.69ms
99.990% 31.36ms
99.999% 31.36ms
100.000% 31.36ms
. . .

висновок

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

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