Бенчмаркинг ньокки для удовольствия и прибыли

Инструмент командной строки поддерживает этот  --verbose переключатель, чтобы иметь подробный отчет о ходе выполнения теста. Пока он поддерживает только метрические операции, но это самая интересная часть ньокки.

Ускоряя некоторые аппаратные средства

У меня есть пара голых металлических серверов для тестирования Gnocchi. Я посвятил первый Gnocchi и использовал второй в качестве эталонного клиента, подключенного к той же сети. Каждый сервер состоит из 2 × Intel Xeon E5-2609 v3  (всего 12 ядер) и 32 ГБ оперативной памяти. Это обеспечивает много ЦП для параллельной обработки запросов.

Затем я просто выполнил базовую   установку RHEL 7 и запустил devstack,  чтобы ускорить установку  Gnocchi на основе главной ветви, отключив все остальные компоненты OpenStack. Затем я настроил конфигурацию Apache httpd для использования рабочего MPM и увеличил максимальное количество клиентов, которые могут отправлять запрос одновременно.

Я настроил Gnocchi для использования   индексатора PostsgreSQL , как он рекомендован, и   драйвера хранилища файлов на основе Carbonara (собственный механизм хранения Gnocchi). Это означает, что файлы хранились локально, а не в Ceph или Swift. Использование  файлового  драйвера менее масштабируемо (вам нужно работать только на одном узле или использовать технологию, подобную NFS, чтобы делиться файлами), но этого теста было достаточно, чтобы иметь некоторые цифры и профилирование зверя.

Промежуточное программное обеспечение для проверки подлинности OpenStack Keystone не было включено в этой настройке, поскольку это добавило бы некоторую задержку при проверке токена проверки подлинности.

Метрические операции CRUD

Создание метрики довольно быстро. Мне удалось достичь 1500 метрик / с, созданных довольно легко. Удаление теперь асинхронное, что означает, что оно быстрее, чем в Gnocchi 1.2, но все же медленнее, чем создание: можно удалить 300 метрик / с. Это не похоже на огромную проблему, поскольку удаление метрик фактически не используется в производстве.

Получение метрической информации также выполняется довольно быстро и достигает 800 метрик / с. Было бы легко достичь очень высокой пропускной способности для этого, так как это было бы легко кэшировать, но мы не чувствовали необходимости реализовывать это до сих пор.

Другая важная вещь заключается в том, что все эти числа постоянны и едва зависят от количества метрик, уже управляемых ньокки.

Отправка и получение мер

Вставка мер в метрики является одной из самых горячих тем. Начиная с Gnocchi 1.1, отправляемые меры обрабатываются асинхронно, что позволяет намного быстрее выдвигать новые меры. Получение новых номеров по этой функции было довольно интересно.

Количество метрик в секунду, которое вы можете нажать, зависит от размера пакета, то есть количества фактических измерений, которые вы отправляете за вызов. Наивный подход состоит в том, чтобы выдвигать 1 такт на вызов, и в этом случае Gnocchi способен обрабатывать около 600 тактов / с. В пакете, содержащем 100 тактов, количество вызовов в секунду снижается до 450, но, поскольку каждый раз вы нажимаете 100 тактов, это означает, что в Gnocchi отправляется 45 тыс. Тактов в секунду!

Я продвинул тест дальше, вдохновленный недавним  сообщением в блоге InfluxDB, утверждающим, что он набирает 300k очков в секунду  с их новым движком. Я выполнил тот же тест на оборудовании, которое у меня было, примерно в два раза меньше, чем тот, который они использовали. Я добился того, чтобы подтолкнуть Gnocchi к чуть более 120k измерениям в секунду. Если бы у меня было то же аппаратное обеспечение, которое они использовали, я мог бы интерполировать результаты, чтобы получить почти 250 000 тактов в секунду. Очевидно, что вы не можете строго сравнивать Gnocchi и InfluxDB, поскольку они не делают одно и то же, но все равно выглядит намного лучше, чем я ожидал.

Использование пакетов меньшего размера, 1 КБ или 2 КБ, повышает пропускную способность до 125 К / с.

Как насчет получения мер? Ну, на самом деле это тоже довольно быстро. Получение метрики с данными за 1 месяц с интервалом в 1 минуту (это 43 тыс. Баллов) занимает менее 2 секунд.

Хотя на самом деле это медленнее, чем я ожидал. Причина, по-видимому, в том, что размер JSON составляет 2 МБ, а для кодирования требуется много времени для Python. Я исследую это. Еще один момент, который я обнаружил, заключается в том, что по умолчанию Gnocchi возвращает все точки данных для каждой детализации, доступные для запрашиваемого периода, что может удвоить размер возвращаемых данных, если вам это не нужно. Будет легко добавить опцию в API, чтобы получить только то, что вам нужно!

После тестирования это означало, что я смог получить 6 метрик / с в секунду, что соответствует примерно 260 тыс. Тактов / с.

Метрическая  скорость

Новые меры, которые помещаются в Gnocchi, обрабатываются gnocchi-metricd демоном асинхронно  . При выполнении вышеприведенных тестов я столкнулся с очень интересной проблемой: отправка 10k мер по метрике привела бы к  gnocchi-metricd использованию до 2 ГБ ОЗУ и 120% ЦП в течение более 10 минут.

После дальнейших исследований я обнаружил, что  причиной этого был наивный подход, который мы использовали для повторной выборки точек данных в Carbonara с использованием  Pandas . Я  сообщил об ошибке в Pandas,  и автор вышестоящей версии был достаточно любезен, чтобы предоставить хороший обходной путь, который я отправил в  виде запроса  на извлечение документации Pandas.

Я написал исправление для Gnocchi и начал использовать его. Вычисление стандартного набора методов агрегирования (стандартное значение, число, 95%, мин., Максимум, сумма, медиана, среднее) для пакетов по 10 КБ по 1 мере (наихудший сценарий) для одного показателя с показателями по 10 К теперь занимает всего 20 секунд и использует 100 МБ Оперативная память — в 45 раз быстрее. Это означает, что в обычных операциях, где обрабатываются только несколько новых мер, операция обновления метрики занимает всего несколько миллисекунд. Потрясающие!

Сравнение с облакомером

Для сравнения, я быстро запустил тест производительности операций чтения в Ceilometer. Я кормил его одним месяцем выборок на 100 экземпляров, опрошенных каждую минуту. Это составляет примерно 4,3 млн. Проб, которые были введены, и это заняло некоторое время — почти 1 час, тогда как в ньокки это заняло бы меньше минуты. Затем я попытался получить некоторые статистические данные таким же образом, как мы их предоставляем в Gnocchi, что означает агрегирование их в течение 60 секунд за месяц.

Очевидно, что Ceilometer очень медленный. Для вычисления и возврата результата необходимо просмотреть 4M выборок, что занимает много времени. Принимая во внимание, что Gnocchi просто должен получить файл и передать его. Это также означает, что чем больше у вас сэмплов (чем больше времени вы собираете данные и чем больше ресурсов), тем медленнее становится облакометр. Это не проблема с Gnocchi, как я подчеркнул, когда я начал разрабатывать его.

Большинство операций Gnocchi — это  O (log R),  где R — это количество метрик или ресурсов, в то время как большинство операций с облакомером —  O (log S),  где S — это количество выборок (мер). Так как R в миллионы раз меньше, чем S, Gnocchi становится намного быстрее.

И что еще более интересно, это то, что ньокки полностью масштабируется по горизонтали. Добавление большего количества серверов Gnocchi (для метрики API и его фоновой обработки  ) увеличит производительность Gnocchi на количество добавленных серверов.

улучшения

В Gnocchi есть несколько вещей, которые нужно улучшить, например, разбить архивы Carbonara, чтобы сделать их более эффективными, особенно от таких драйверов, как Ceph и Swift. Это уже на моей тарелке, и я с нетерпением жду, чтобы работать над этим!

И если у вас есть какие-либо вопросы, не стесняйтесь задавать их в разделе комментариев.