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

1. Исследование спроса

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

Цели оптимизации можно разделить на бизнес-цели и ресурсные цели. Бизнес-цели делятся на время отклика (среднее время ответа на транзакцию, время ответа 99% транзакций и т. д.), TPS, уровень успешности и другие показатели. Целевые ресурсы можно разделить на такие индикаторы, как загрузка ЦП, использование памяти, использование диска и использование полосы пропускания сети. Оптимизация производительности практически бесконечна, и у вас должны быть четкие цели, чтобы избежать слишком рентабельных инвестиций.

Что касается бизнес-процессов, то преимущество их понимания состоит в том, что вы можете оценить, является ли стратегия стресс-тестирования разумной. Например, в сценарии флэш-продажи необходимо смоделировать мгновенную пиковую нагрузку с помощью метода «высокий уровень параллелизма + точка встречи».

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

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

2. Доступ

На этапе допуска необходимо рассмотреть условия допуска, то есть какие условия выполняются для начала работ по настройке производительности. Общие условия приема следующие.

1) Оптимизируемая версия имеет стабильную среду стресс-тестирования и данные результатов стресс-тестирования.

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

2) Результаты стресс-тестирования не соответствуют ожидаемым бизнес-целям производительности или целям использования ресурсов.

Нет предела настройке производительности. Чтобы не попасть в слепую настройку с бесконечной низкой стоимостью производительности, необходимо проверить, соответствуют ли показатели производительности, такие как использование, ожидаемым бизнес-целям. Если оно не удовлетворено, выполните настройку; если оно удовлетворено, перед выполнением последующей настройки бизнес-сторона должна указать разумную причину.

3) Оснащены соответствующими инструментами настройки.

Данные, отображаемые инструментом настройки, являются основой для определения узкого места в производительности. Настройщику необходимо получить данные с помощью инструмента, чтобы подтвердить основную причину узкого места в производительности. Только так мы сможем быстро предложить решения и оптимизировать их. Например, проблему взаимоблокировки можно проанализировать с помощью JVisuaIVM, а проблему утечки памяти можно проанализировать с помощью MAT.

4) Тестируемое приложение, связанные приложения и связанные базы данных проверены.

Обычно в процессе стресс-тестирования мы будем отслеживать тестируемое приложение. На этом этапе нам необходимо обратить внимание на тот факт, что тестируемое приложение, вероятно, будет зависеть от других служб или баз данных. Эти связанные приложения и базы данных должны быть зависимы. иметь доступ и контролироваться вместе. Мониторинг должен быть максимально подробным, включая мониторинг аппаратных ресурсов, мониторинг JVM, мониторинг баз данных и т. д. Если архитектура системы относительно сложна и зависимости неясны, вы можете использовать инструменты APM, чтобы разобраться в связях. Опытные настройщики также могут использовать дамп сети или потока, чтобы проанализировать наличие внешних зависимостей. Например, используйте команду netstat, чтобы проанализировать, взаимодействует ли служба с внешними IP-адресами или портами. Дамп потока также может определить, в каком бизнес-методе она отображается. внешние услуги.

3. Настройка и внедрение

Процесс реализации тюнинга следующий.

1) Поймите явление узкого места в производительности.

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

2) Проанализируйте основную причину и последствия проблемы.

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

3) Проанализируйте экономическую эффективность плана оптимизации и определите план оптимизации.

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

4) Проверьте эффект оптимизации.

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

4. Выходите аккуратно

Условия выхода относятся к условиям, которые должны быть выполнены для завершения работы по настройке производительности. Ниже приведены общие условия выхода.

1) После оптимизации производительность соответствует показателям производительности.

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

2) Будут ли затронуты после оптимизации другие бизнес-функции.

Любая оптимизация производительности не должна осуществляться в ущерб функциональной корректности. Если нет уверенности в том, повлияет ли оптимизация производительности на бизнес-логику, после оптимизации следует выполнить функциональное регрессионное тестирование, чтобы убедиться, что функция не затронута.

5. Накопление базы знаний В процессе настройки производительности нам необходимо обобщить полезный опыт и сформировать базу знаний для его накопления.

Основная работа на этом этапе заключается в следующем:

1) Организовать и записать документы процесса настройки.

Выявляйте узкие места в производительности, разрабатывайте планы настройки, записывайте результаты оптимизации и постепенно формируйте актив для внутренней базы знаний по настройке компании.

2) Рассмотрите все исторические проблемы до завершения проекта.

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

3) Регулярно расширяйте возможности команды внутри и снаружи и создайте механизм обучения градиенту талантов.

Регулярно делитесь или обучайте базе знаний по настройке и методам устранения неполадок, соответствующим проблемам, правилам между явлениями и первопричинами и т. д., чтобы избежать попадания в те же «ловушки» других бизнес-направлений или проектных групп и улучшить общее качество решения проблем командой. идеи и технический уровень. Проблемы можно классифицировать, а проблемы и решения, которые возникают чаще и имеют четкие пути устранения неполадок и методы настройки, можно расставить по приоритетам и поделиться ими.