Доброго времени суток, Хабр. Речь пойдёт об инструменте тестирования производительности СХД (систем хранения данных), изначально разработанного в недрах компании EMC для внутренних нужд, но имеющем свойство плавно разрастаться. Кстати, буквально «вчера» мангуст получил статус OpenSource проекта. А это значит, что пришло время немножко рассказать о нём. Итак, что же это за зверь?

Основные особенности

1. Распределённый режим
   Представляет собой способ выполнения задач нагрузки одновременно с многих узлов сети с централизованным контролем и сбором метрик. Упрощённая иллюстрация из документации:
   
   Позволяет существенно увеличить нагрузку на распределённые СХД, эмулируя запросы большого количества пользователей.
   
   
2. Отчётность
   
   • Выходные файлы со списками обработанных объектов (файлов, ...), которые можно снова использовать на входе
   • Доступность временных отметок высокого разрешения (мкс) для каждой отдельной операции
   
   
3. CRUD (Create/Read/Update/Delete) — доступные типы I/O операций для создания нагрузки
   
4. Поддержка различных типов СХД:
   
   • Amazon S3 REST API
   • EMC Atmos REST API
   • OpenStack Swift REST API
   • Файловая система (local, NFS mount, ...)
   
   
5. Поддерживаемые типы объектов:
   
   • Контейнеры (они же каталоги в случае ФС, они же bucket'ы в случае S3)
   • Данные (файлы в случае работы с файловой системой)
   
   
6. Верификация данных при выполнении операции чтения
7. Генерация произвольных данных (несжимаемый равномерный шум, текст или одинаковые байты)
8. Язык сценариев
9. «Заглушка»: HTTP-сервер, реализующий функции облачной СХД, который не хранит данные, но умеет отдавать их обратно при чтении. По сути, storage mock для тестирования функционала и производительности самого мангуста. Тяготеет к тому, чтобы вскоре стать распределённой заглушкой, а также драйвером ФС.
   
10. Web GUI
11. И много других замечательных вещей, перечисление которых займёт слишком много места.

Известные аналоги

• Apache JMeter
  Аналог очень условный и имеющий столь мало общего с мангустом, что сравнение практически невозможно.
  
• COSBench (Intel)
  Более близкий по функционалу аналог, чем JMeter.
  Достоинства: имеет более длинную историю разработки и больше активных разработчиков, поддерживает более широкий спектр СХД.
  
  Недостатки: уступает по ряду функциональных пунктов (генерация произвольных данных, например) и производительности (не решает т.н. проблемы «С10К»).
  
  

Несколько слов о высокой нагрузке

Так как инструмент тестирования производительности должен создавать высокую I/O нагрузку, то сам этот инструмент должен быть очень производительнным, а расходовать ресурсы окружения он должен очень эффективно.

1. Решение проблемы C10K
   В ранних версиях мангуста потоки выполнения были привязаны к соответствующим соединениям. Очень быстро стало ясно, что такой подход порочен. При работе с объектами большого размера при большом количестве потоков показатели производительности были особенно плохими. Однако после применения событийно-ориентированного асинхронного I/O, результаты стали впечатлять. Инструмент продемонстрировал работоспособность даже при 1 миллионе одновременно открытых соединений, причём даже без применения distributed mode, позволяющего кратно увеличивать это количество.
   
   
   
   
2. Zero Copy везде, где это возможно
3. Автоматическая конфигурация размеров I/O буферов исходя из известных размеров передаваемых данных. Маленькие объекты — меньше буфер, большие объекты — больше буфер. Запись — больше выходной буфер, чтение — больше входной буфер. Собственно, буферы располагаются в Direct Memory для обеспечения Zero Copy

Как это выглядит на практике

После того как вы скачали tarball с последней версией и распаковали его, запуск мангуста происходит до безобразия просто:

java -jar mongoose-<VERSION>/mongoose.jar

Это приведёт к попытке мангуста делать всё по умолчанию:

• Выполнять создание новых объектов (create) вечно (пока не прервёт пользователь)
• Использовать S3 API (т.е. генерировать HTTP запросы)
• Использовать 1 соединение к адресу по умолчанию (127.0.0.1:9020)

Чтобы увидеть что-то кроме ошибок в таком случае, можно попробовать запустить на той же машине «заглушку» (которая будет выполнять функции storage mock):

java -jar mongoose-<VERSION>/mongoose.jar wsmock

Для желающих использовать GUI потребуется выполнить следующую команду:

java -jar mongoose-<VERSION>/mongoose.jar webui

И перейти в браузере по адресу 127.0.0.1:8080.


Ещё одной важной особенностью являются пользовательские сценарии. Сценарий записываются в формате JSON и может быть указан при запуске следующим образом

java -jar mongoose-<VERSION>/mongoose.jar -f <PATH_TO_SCENARIO_FILE>.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, ...)
• Поддержка СУБД (?)