[Из песочницы] Mongoose: инструмент для тестирования производительности СХД
Доброго времени суток, Хабр. Речь пойдёт об инструменте тестирования производительности СХД, изначально разработанного в недрах компании EMC для внутренних нужд, но имеющем свойство плавно разрастаться. Кстати, буквально «вчера» мангуст получил статус OpenSource проекта. А это значит, что пришло время немножко рассказать о нём. Итак, что же это за зверь?
Так как инструмент тестирования производительности должен создавать высокую I/O нагрузку, то сам этот инструмент должен быть очень производительнным, а расходовать ресурсы окружения он должен очень эффективно.
После того как вы скачали tarball с последней версией и распаковали его, запуск мангуста происходит до безобразия просто:
Это приведёт к попытке мангуста делать всё по умолчанию:
Чтобы увидеть что-то кроме ошибок в таком случае, можно попробовать запустить на той же машине «заглушку» (которая будет выполнять функции storage mock):
И перейти в браузере по адресу 127.0.0.1:8080.
Один из простейших сценариев выглядит следующим образом:
Этот сценарий используется мангустом по умолчанию, когда никакой другой файл сценария не указан явно. Чуть более сложный пример сценария:
К моменту написания статьи последней стабильной версией является 2.4.1. В настоящее время ведётся активная разработка версии 3, в которой будет применена новая архитектура (монитор — генератор — драйвер — монитор), открывающая новые возможности для распределённого режима работы и сценариев типа «weighted load».
Основные особенности
- Распределённый режим
Позволяет выполнять задачи по нагрузке одновременно с многих узлов сети, сохраняя при этом централизованный контроль и сбор метрик. - Отчётность
- Выходные файлы со списками обработанных объектов (файлов, …), которые можно снова использовать на входе
- Доступность временных отметок высокого разрешения (мкс) для каждой отдельной операции
- CRUD (Create/Read/Update/Delete) — доступные типы I/O операций для создания нагрузки
- Поддержка различных типов СХД:
- Amazon S3 REST API
- EMC Atmos REST API
- OpenStack Swift REST API
- Файловая система (local, NFS mount, …)
- Поддерживаемые типы объектов:
- Контейнеры (они же каталоги в случае ФС, они же bucket’ы в случае S3)
- Данные (файлы в случае работы с файловой системой)
- Верификация данных при выполнении операции чтения
- Генерация произвольных данных (несжимаемый равномерный шум, текст или одинаковые байты)
- Язык сценариев
- «Заглушка»: HTTP-сервер, реализующий функции облачного СХД, который не хранит данные, но умеет отдавать их обратно при чтении. По сути, storage mock для тестирования функционала и производительности самого мангуста. Тяготеет к тому, чтобы вскоре стать распределённой заглушкой, а также драйвером ФС.
- Web GUI
- И много других замечательных вещей, перечисление которых займёт слишком много места.
Известные аналоги
- Apache JMeter
Аналог очень условный и имеющий столь мало общего с мангустом, что сравнение практически невозможно. - COSBench (Intel)
Более близкий по функционалу аналог, чем JMeter.
Достоинства: имеет более длинную историю разработки и больше активных разработчиков, поддерживает более широкий спектр СХД.Недостатки: уступает по ряду функциональных пунктов (генерация произвольных данных, например) и производительности (не решает т.н. проблемы «С10К»).
Несколько слов о высокой нагрузке
Так как инструмент тестирования производительности должен создавать высокую I/O нагрузку, то сам этот инструмент должен быть очень производительнным, а расходовать ресурсы окружения он должен очень эффективно.
- Решение проблемы C10K
В ранних версиях мангуста потоки выполнения были привязаны к соответствующим соединениям. Очень быстро стало ясно, что такой подход порочен. При работе с объектами большого размера при большом количестве потоков показатели производительности были особенно плохими. Однако после применения событийно-ориентированного асинхронного I/O, результаты стали впечатлять. Инструмент продемонстрировал работоспособность даже при 1 миллионе одновременно открытых соединений. - Zero Copy везде, где это возможно
- Автоматическая конфигурация размеров I/O буферов исходя из известных размеров передаваемых данных. Маленькие объекты — меньше буфер, большие объекты — больше буфер. Запись — больше выходной буфер, чтение — больше входной буфер. Собственно, буферы располагаются в Direct Memory для обеспечения Zero Copy
Как это выглядит на практике
После того как вы скачали tarball с последней версией и распаковали его, запуск мангуста происходит до безобразия просто:
java -jar mongoose-/mongoose.jar
Это приведёт к попытке мангуста делать всё по умолчанию:
- Выполнять создание новых объектов (create) вечно (пока не прервёт пользователь)
- Использовать S3 API (т.е. генерировать HTTP запросы)
- Использовать 1 соединение к адресу по умолчанию (127.0.0.1:9020)
Чтобы увидеть что-то кроме ошибок в таком случае, можно попробовать запустить на той же машине «заглушку» (которая будет выполнять функции storage mock):
java -jar mongoose-/mongoose.jar wsmock
Для желающих использовать GUI потребуется выполнить следующую команду:
java -jar mongoose-/mongoose.jar webui
И перейти в браузере по адресу 127.0.0.1:8080.
Ещё одной важной особенностью являются пользовательские сценарии. Сценарий записываются в формате JSON и может быть указан при запуске следующим образом
java -jar mongoose-/mongoose.jar -f .json
Один из простейших сценариев выглядит следующим образом:
{
"type": "load"
}
Этот сценарий используется мангустом по умолчанию, когда никакой другой файл сценария не указан явно. Чуть более сложный пример сценария:
{
"type" : "for",
"value" : "threads",
"in" : [
1, 10, 100, 1000, 10000, 100000
],
"config" : {
"load" : {
"threads" : "${threads}"
}
},
"jobs" : [
{
"type" : "load"
}
]
}
Более детальная информация об использовании доступна в разделе «Documentation» на сайте мангуста.
Что дальше?
К моменту написания статьи последней стабильной версией является 2.4.1. В настоящее время ведётся активная разработка версии 3, в которой будет применена новая архитектура (монитор — генератор — драйвер — монитор), открывающая новые возможности для распределённого режима работы и сценариев типа «weighted load».
В планах на будущее также есть следующее:
- Расширение возможностей Web GUI
- Реализация операций неполного (частичного) чтения данных
- Расширение спектра поддерживаемых типов СХД (Google Cloud Storage, EMC Centera, …)
- Поддержка СУБД (?)