[Оптимизация производительности (часть 2)] Сценарный анализ общих проблем с производительностью

задняя часть

предисловие

существует[Оптимизация производительности (часть 1)] Вы действительно понимаете свою систему?В , мы научились оценивать нашу собственную систему и узнали о различных показателях оценки системы. В сегодняшней статье в основном говорится о том, как определить направление оптимизации, а также о некоторых распространенных сценариях и методах оптимизации, вызывающих проблемы с производительностью.

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

jvm тюнинг? Оптимизация SQL? перестроить код? когда начать

Существуют тысячи методов оптимизации, но как определить направление оптимизации? Как только это всплывает, Ka Ka Ka является регулировкой параметров JVM, Операция жестока, как тигр, а эффект равен 0,5 с первого взгляда. Подходит ли прямая настройка JVM? Да, но не обязательно. Сначала нужно найти наибольшую часть системыузкое место производительностиНачните и получите максимальную отдачу от затраченных средств.

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

монитор

Мы можем найти узкие места производительности в системе с помощью различных методов мониторинга, таких как:

  1. Журналы медленных запросов, MYSQL, Redis и другие журналы медленных запросов, SQL-> Интерфейс-> Проблемы с производительностью функций
  2. Мониторинг ссылок APM для микросервисной архитектуры APM является обязательным. Благодаря статистике ссылок APM мы можем получить большое количество эффективных индикаторов, включая строки RT99, трудоемкую сортировку запросов, анализ ссылок, SLA и т. д., которые очень помогают нам анализировать узкие места производительности или проблемы с производительностью.
    ...

APM может разрабатывать самостоятельно или использовать фреймворки с открытым исходным кодом.Сейчас доступно множество фреймворков, в том числе: skywalking, zipkin, pinpoint, esapm и т. д., каждый со своими преимуществами и недостатками, вы можете сравнить и выбрать самостоятельно.

Стресс-тест полной ссылки

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

Если вы находитесь в следующих ситуациях, вы можете рассмотреть возможность проведения полносвязного стресс-теста:

  1. Узкое место системы не может быть найдено при текущем уровне доступа
  2. Имейте четкие цели производительности
  3. Определить предельный индекс системы

У полносвязного стресс-тестирования много преимуществ, но есть только один недостаток — дороговизна! В случае крупномасштабной системы испытание под давлением может стоить сотни тысяч юаней.

Фронтальная обратная связь

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

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

Распространенные проблемы с производительностью и решения

Давайте поговорим о некоторых распространенных сценариях и решениях, вызывающих проблемы с производительностью.

проблема дизайна

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

блокировка запроса

Маленькие инциденты, большие проблемы. Скорость обработки запросов в наибольшей степени обусловлена ​​накоплением потоков

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

  1. Загрузка ЦП растет -> влияет на RT -> потоки продолжают накапливаться

  2. Использование памяти растет -> FullGC можно использовать повторно -> продолжает расти -> FullGC

  3. Рост использования памяти -> не перерабатывается -> OOM

Общие сценарии

Общие сценарии блокировки запросов могут включать следующее:

  • Зависимая нижестоящая служба ненормальна, что приводит к накоплению потоков логической обработки самой службы.
  • Но тяжелая бизнес-логика сочетается с основной логикой.
  • запрос, у MySQL или Redis медленный запрос
  • ...

взять каштан


def login(username, password):
 """
     用户登录接口
        """
 # do something
 user = doLogin(username, password)
 report(user)
    
def report(user):
 # 数据上报 timeout = -1即无限等待
 http.post(user, timouet = -1)

Выше приведена очень простая логика входа в систему. Сначала войдите в систему. После успешного входа в систему необходимо сообщить о событии на платформу данных. В чем проблема?

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

Приведенный выше код может привести к блокировке, что, в свою очередь, сделает сервис недоступным. Итак, как мы можем его оптимизировать?

Ссылаться на

  • Асинхронный
  • Добавить обработку исключений
  • увеличить время ожидания
  • Добавьте предохранители и меры по ограничению тока

как избежать

  • Изоляция, изоляция основной логики и неосновной логики посредством асинхронности, разделения или изоляции по дизайну
  • Тайм-аут, все внешние зависимости желательно иметь настройку тайм-аута
  • Защита от фьюзинга, внешние сервисы должны иметь соответствующие меры по фьюзингу
  • Хорошее знание SQL и кода, комплексное тестирование (параллелизм, исключения)

запросить распространение

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

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

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

Общие сценарии

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

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

как избежать

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

взрыв кеша

Неограниченный локальный кеш

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

Общие сценарии

Общие сценарии взрыва кэша могут включать следующее:

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

как избежать

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

Замок

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

Например, в Java, когда существует большая конкуренция блокировок, возникает явление укрупнения блокировок, от предвзятых блокировок до тяжеловесных блокировок, и при ожидании и пробуждении необходимо выполнять системные вызовы. Что касается блокировки в Java, вы можете проверить соответствующую информацию~

Общие сценарии

Общие сценарии проблем с производительностью, вызванных блокировками, могут включать следующее:

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

как избежать

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

Заблокируйте оптимизацию производительности в общих фреймворках:

  1. Druid и hikariCP — это два пула соединений с БД. HikariCP заменяет блокировки большим количеством операций CAS. В стресс-тесте производительность почти вдвое выше, чем у Druid. Недостатком является то, что CAS приводит к увеличению использования ЦП.
  2. log4j2 использует инфраструктуру параллелизма Disruptor (большое количество lock-free) вместо операций блокировки, и его производительность в стресс-тестировании намного лучше, чем у log4j и logback.

пул соединений

Чем больше пул соединений, тем лучше?
Мы используем различные пулы потоков или при использовании пулов подключения к данным мы когда-либо сталкивались с ситуацией, когда скорость подключения очень низкая? Ваш ответ заключается в том, что пула соединений недостаточно, а затем увеличить количество пулов соединений?

Действительно ли пул соединений чем больше, тем лучше?

Когда ЦП выполняет переключение потоков, возникает стоимость переключения контекстов.Цель многопоточности состоит в том, чтобы лучше использовать время простоя ЦП (например, сетевой ввод-вывод соединения с БД). Но когда скорость обработки программы в нашем потоке очень высока, частое переключение контекста будет замедлять скорость нашей программы.

Как правильно настроить пул соединений

Значение опыта, рекомендованное официальным сайтом HikariCP, составляет:connections = ((core_count * 2) + effective_spindle_count), например 4-ядерный сервер с жестким диском, то пул соединений можно установить равным (4 * 2) + 1 = 9, и он может колебаться вверх и вниз в зависимости от реальной ситуации в производственной среде.

Во время нашего процесса стресс-тестирования был этап, когда узкое место застревало на соединении с БД, и феномен заключался в том, что в ссылке APM большая часть времени тратилась на метод getConnection. Количество экземпляров нашего приложения составляет около 100, а конфигурация пула соединений с БДmax-active = 60. При столкновении с этим узким местом первоначальная попытка увеличить количество соединений, изменитьmax-active=80, был увеличен до 120, узкое место все еще там, и он медленнее. Наконец, попробуйте уменьшить количество подключений.max-active = 10, узкое место исчезло, а показатель производительности вырос почти в 2 раза.

Обратите внимание на влияние переключения контекста процессора. Разумно установите количество всех пулов потоков, чем больше потоков, тем лучше

Нижняя линия

Суть в том, что предохранители и ограничение тока необходимы

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

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

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

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

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

  • Автоматическое восстановление
    Когда служба вернется в нормальное состояние, она может быть автоматически восстановлена.

Эпилог

Наконец, мы резюмируем содержание всей статьи по оптимизации производительности:

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

Я все это видел, ставь лайк и уходи~

Категории