[Python, Microsoft Azure, Тестирование веб-сервисов, Облачные сервисы] HTTP атака на Azure
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Будем ломать веб-сервер и закидывать его пачками HTTP запросов. Потихоньку заполнять всё вокруг HTTP-флудом и наблюдать полнейшую деградацию. Готовься Azure, будет не до смеха!Если чуть серьёзнее, то выполняя стандартные лабы по знакомству с Azure в рамках AZ-900 Microsoft Azure Fundamentals решил посмотреть на что способна одна из минимальных конфигураций виртуальных машин Standard B1s (1 GiB RAM, 1 vCPU).В стандартных лабах на виртуалку ставится веб-сервер вроде Apache или IIS, запускается простенький сайт и на этом всё заканчивается. Мне показалось такого знакомства мало и стало интересно посмотреть, как сервер будет реагировать на большое количество запросов, что станется с временем ответа и, главное, поможет ли изменения размера виртуалки улучшить качество работы. Кроме того, чтобы добавить серверу забот, на виртуалке с Ubuntu был поднят WordPress (Apache, MySQL, PHP). Для теста использовался скрипт на Python, который непрерывно генерил GET запросы на один и тот же адрес.В случае с одиночными запросами время ответа сервера не превышало 300-400 мс, что для такой конфигурации выглядело вполне приемлемым.Другое дело, как сервер будет реагировать на массовые запросы, когда GET прилетают пачками. На Python такие параллельные запросы можно реализовать используя модуль “concurrent.futures”, который дает доступ к высокоуровневому интерфейсу для асинхронных вызовов. Идея реализации была вдохновлена ресурсом creativedata.stream. В итоге, для теста сервер был атакован волной GET запросов с линейно возрастающим количеством одновременных запросов. Для большей наглядности время ожидания ответа на каждый запрос было ограничено 10 секундами. Для каждой попытки отправлялось 5000 запросов.Результаты теста для VM Standard B1s приведены в таблицеКол-во параллельных GET запросовВремя теста (с)Среднее время ответа (с)Максимальное время ответа (с)Количество отказов 10246 0.4825041.393406020183 0.7162271.775027030158 0.9258032.239563040133 1.02899510.3894134773После попытки с 40 одновременными запросами стало ясно, что сервер не справляется, и количество ответов отличных от “200” начало приближаться к 100%.Давайте взглянем на графики производительности виртуальной машины. Загрузка ЦПУ прямо пропорциональна интенсивности тестовой нагрузки. Оперативная память также не пролазит в бутылочное горлышко.
Standard B1s PerfomanceКак повёдет себя сервер, после изменения размера виртуальной машины. Пара кликов и B1s превращается в Standard B2s (4GiB RAM, 2 vCPU). Получится ли от двух ЦПУ получить двухкратный прирост?Повторяем тест, но чуть увеличиваем шаг. Количество запросов в каждой попытке устанавливаем в 10000.Результаты теста для VM Standard B2s приведены в таблицеКол-во параллельных GET запросовВремя теста (с)Среднее время ответа (с)Максимальное время ответа (с)Количество отказов 20198 0.3873101.377070040171 0.6604141.481950060140 0.8086571.674038080130 1.0019152.14215701001191.1634762.2522310120119 1.4172232.7034180140119 1.6546392.987740160119 1.9010405.6222940Как и в первом тесте график загрузки ЦПУ и использования памяти прямо пропорционален количеству одновременных запросов. Однако, полнейшей деградации сервиса добиться не удалось. Хоть и с двух секундным таймаутом, но сервер иправно отвечал на все запросы.
Standard B2s Perfomance
Standard B2s MonitoringПри 160 одновременных запросах нагрузка на сеть уже со стороны тестовой утилиты достигала 5Mb/s и дальнейшее увеличение количества одновременных запросов было решено не проводить.Место для выводов
Данный тест с HTTP-флудом и текущей реализацией не претендуют на покорение космоса и следование золотым стандартам. Однако, тесты продемонстрировали ожидаемую прямую зависимость между количеством одновременных запросов и загрузкой на ЦПУ, память и средним и максимальным временем ответа.Судя по всему, сервер с большим объемом оперативной памяти (4Gb против 1Gb) справляется с такого рода нагрузкой лучше и даже при 5-ти кратном увеличением количества запросов (160 против 30) исправно отвечает 200 ОК!PSПример тествой утилиты доступен в моём репозитории на github
===========
Источник:
habr.com
===========
Похожие новости:
- [Тестирование IT-систем, Тестирование веб-сервисов] Процесс автоматизированного тестирования за 10 шагов (перевод)
- [.NET] A little life hack when you work with Azure Service Bus and ASP.NET Core
- [Python, Программирование, Программирование микроконтроллеров] Маленькие Python для маленьких embedded-программистов: CircuitPython и MicroPython для MeowBit
- [Системное администрирование, Управление проектами, DevOps, Облачные сервисы] Закупки как сервис
- [Хостинг, Хранение данных, Законодательство в IT, Облачные сервисы] Лицензии связи
- [Тестирование IT-систем, Тестирование веб-сервисов, Учебный процесс в IT, Карьера в IT-индустрии] ISTQB. Как проходит сдача экзамена онлайн
- [Беспроводные технологии, Разработка систем связи, Законодательство в IT, Сотовая связь] «Ростелеком» могут допустить к тестированию 5G на частотах 3,4–3,8 ГГц в метро
- [Программирование, Облачные сервисы, IT-компании] Обладательница фамилии True полгода не может воспользоваться своим аккаунтом в Apple iCloud
- [Python, SQL] Cобеседование на позицию стажера в Яндекс на аналитика данных
- [Python, Обработка изображений] Перегон картинок из Pillow в NumPy/OpenCV всего за два копирования памяти
Теги для поиска: #_python, #_microsoft_azure, #_testirovanie_vebservisov (Тестирование веб-сервисов), #_oblachnye_servisy (Облачные сервисы), #_azure, #_http, #_apache, #_testirovanie (тестирование), #_oblachnye_servisy (облачные сервисы), #_python, #_python3, #_wordpress, #_python, #_microsoft_azure, #_testirovanie_vebservisov (
Тестирование веб-сервисов
), #_oblachnye_servisy (
Облачные сервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 05:20
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Будем ломать веб-сервер и закидывать его пачками HTTP запросов. Потихоньку заполнять всё вокруг HTTP-флудом и наблюдать полнейшую деградацию. Готовься Azure, будет не до смеха!Если чуть серьёзнее, то выполняя стандартные лабы по знакомству с Azure в рамках AZ-900 Microsoft Azure Fundamentals решил посмотреть на что способна одна из минимальных конфигураций виртуальных машин Standard B1s (1 GiB RAM, 1 vCPU).В стандартных лабах на виртуалку ставится веб-сервер вроде Apache или IIS, запускается простенький сайт и на этом всё заканчивается. Мне показалось такого знакомства мало и стало интересно посмотреть, как сервер будет реагировать на большое количество запросов, что станется с временем ответа и, главное, поможет ли изменения размера виртуалки улучшить качество работы. Кроме того, чтобы добавить серверу забот, на виртуалке с Ubuntu был поднят WordPress (Apache, MySQL, PHP). Для теста использовался скрипт на Python, который непрерывно генерил GET запросы на один и тот же адрес.В случае с одиночными запросами время ответа сервера не превышало 300-400 мс, что для такой конфигурации выглядело вполне приемлемым.Другое дело, как сервер будет реагировать на массовые запросы, когда GET прилетают пачками. На Python такие параллельные запросы можно реализовать используя модуль “concurrent.futures”, который дает доступ к высокоуровневому интерфейсу для асинхронных вызовов. Идея реализации была вдохновлена ресурсом creativedata.stream. В итоге, для теста сервер был атакован волной GET запросов с линейно возрастающим количеством одновременных запросов. Для большей наглядности время ожидания ответа на каждый запрос было ограничено 10 секундами. Для каждой попытки отправлялось 5000 запросов.Результаты теста для VM Standard B1s приведены в таблицеКол-во параллельных GET запросовВремя теста (с)Среднее время ответа (с)Максимальное время ответа (с)Количество отказов 10246 0.4825041.393406020183 0.7162271.775027030158 0.9258032.239563040133 1.02899510.3894134773После попытки с 40 одновременными запросами стало ясно, что сервер не справляется, и количество ответов отличных от “200” начало приближаться к 100%.Давайте взглянем на графики производительности виртуальной машины. Загрузка ЦПУ прямо пропорциональна интенсивности тестовой нагрузки. Оперативная память также не пролазит в бутылочное горлышко.  Standard B1s PerfomanceКак повёдет себя сервер, после изменения размера виртуальной машины. Пара кликов и B1s превращается в Standard B2s (4GiB RAM, 2 vCPU). Получится ли от двух ЦПУ получить двухкратный прирост?Повторяем тест, но чуть увеличиваем шаг. Количество запросов в каждой попытке устанавливаем в 10000.Результаты теста для VM Standard B2s приведены в таблицеКол-во параллельных GET запросовВремя теста (с)Среднее время ответа (с)Максимальное время ответа (с)Количество отказов 20198 0.3873101.377070040171 0.6604141.481950060140 0.8086571.674038080130 1.0019152.14215701001191.1634762.2522310120119 1.4172232.7034180140119 1.6546392.987740160119 1.9010405.6222940Как и в первом тесте график загрузки ЦПУ и использования памяти прямо пропорционален количеству одновременных запросов. Однако, полнейшей деградации сервиса добиться не удалось. Хоть и с двух секундным таймаутом, но сервер иправно отвечал на все запросы.  Standard B2s Perfomance  Standard B2s MonitoringПри 160 одновременных запросах нагрузка на сеть уже со стороны тестовой утилиты достигала 5Mb/s и дальнейшее увеличение количества одновременных запросов было решено не проводить.Место для выводов Данный тест с HTTP-флудом и текущей реализацией не претендуют на покорение космоса и следование золотым стандартам. Однако, тесты продемонстрировали ожидаемую прямую зависимость между количеством одновременных запросов и загрузкой на ЦПУ, память и средним и максимальным временем ответа.Судя по всему, сервер с большим объемом оперативной памяти (4Gb против 1Gb) справляется с такого рода нагрузкой лучше и даже при 5-ти кратном увеличением количества запросов (160 против 30) исправно отвечает 200 ОК!PSПример тествой утилиты доступен в моём репозитории на github =========== Источник: habr.com =========== Похожие новости:
Тестирование веб-сервисов ), #_oblachnye_servisy ( Облачные сервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 05:20
Часовой пояс: UTC + 5