Настройка производительности распределенного приложения

  • Статья

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

Сценарии:

Как оценивается производительность

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

Установите требуемый уровень обслуживания, определяющий целевые показатели производительности для каждой рабочей нагрузки. Обычно эта цель достигается путем нарушения целевой цели производительности в набор ключевых показателей эффективности (КПЭ), таких как:

  • задержка или время отклика для определенных запросов;
  • число запросов, выполняемых в секунду;
  • скорость, с которой система создает исключения.

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

Примером SLO может быть "Запросы клиентов имеют ответ в пределах 500 мс @ P90, при загрузке до 25 K запросов/секунд".

Трудности при настройке производительности распределенной системы

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

  • В выполнении одной бизнес-транзакции или операции обычно участвуют несколько компонентов системы. Получить целостное представление обо всем процессе выполнения отдельной операции иногда затруднительно.

  • Потребление ресурсов распределяется между несколькими узлами. Чтобы получить полное представление, необходимо агрегировать данные журналов и метрик в одном расположении.

  • Облачные технологии обеспечивают возможность эластичного масштабирования. Важную роль играет функция автомасштабирования, позволяющая справляться с пиками нагрузки. Но она также может маскировать базовые проблемы. Кроме того, бывает трудно выяснить, какие компоненты и в каких случаях необходимо масштабировать.

  • Рабочие нагрузки часто не масштабироваться между ядрами или потоками. Важно понять требования рабочих нагрузок и ознакомиться с более оптимизированными размерами. Некоторые размеры предлагают ограниченные ядра и отключенные гиперпотоки для улучшения одноядерных ориентированных и для каждой лицензированной рабочей нагрузки.

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

Общие рекомендации

Настройка производительности требует определенных навыков и знаний. Преимущество при этом обеспечит системный подход. Вот некоторые рекомендации:

  • Включите сбор данных телеметрии для получения метрик. Инструментируйте свой код. Следуйте рекомендациям по мониторингу. Используйте коррелированную трассировку, чтобы отслеживать все шаги в транзакции.

  • Отслеживайте производительность для 90-го, 95-го и 99-го процентилей, а не только средние значения. Средние значения могут маскировать выбросы. Частота выборки метрик также важна. Если частота выборки слишком мала, она может скрыть пики или выбросы, которые могут указывать на проблемы.

  • Устраняйте проблемы по очереди. Сформулируйте гипотезу и проверьте ее, изменяя одну переменную за раз. Устранение одной проблемы обычно позволяет обнаружить следующую либо в серверной, либо в интерфейсной части.

  • Ошибки и повторные попытки могут оказывать значительное влияние на производительность. Если вы видите, что серверные службы регулируют систему, масштабируют или пытаются оптимизировать использование (например, настраивая запросы базы данных).

  • Ознакомьтесь с распространенными неправильными подходами, снижающими производительность.

  • Ищите возможности для параллельного выполнения. Двумя распространенными источниками снижения производительности являются очереди сообщений и базы данных. В обоих случаях может помочь сегментирование. Дополнительные сведения см. в статье о горизонтальном, вертикальном и функциональном секционировании данных. Определите горячие секции, которые могут указывать на несбалансированные нагрузки при чтении или записи.

Следующие шаги

Ознакомьтесь со сценариями настройки производительности