[Из песочницы] Mongoose: инструмент для тестирования производительности СХД

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

image

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


  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 миллионе одновременно открытых соединений.

    818343149_4347189.jpg

  2. Zero Copy везде, где это возможно
  3. Автоматическая конфигурация размеров 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.
default_start_with_captures.gif

Ещё одной важной особенностью являются пользовательские сценарии. Сценарий записываются в формате 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».

latest?cb=20120116090655

В планах на будущее также есть следующее:

  • Расширение возможностей Web GUI
  • Реализация операций неполного (частичного) чтения данных
  • Расширение спектра поддерживаемых типов СХД (Google Cloud Storage, EMC Centera, …)
  • Поддержка СУБД (?)

Комментарии (0)

© Habrahabr.ru