1. Введение
На этот раз нагрузочному тестированию подвергается модуль.Этот модуль обеспечивает интерфейс HTTPS с внешним миром.Не нужно обращать внимание на конкретные функции.В этой статье в основном представлены точки оптимизации производительности и идеи по оптимизации, найденные в ходе всего процесса стресс-тестирования. . Сначала будут выброшены результаты стресс-теста, и вы сначала подумаете, почему, так что отложите анализ.
2. Измерение и анализ давления
Этот стресс-тест в основном предназначен для проверки ЦП, поскольку обнаружено, что колебания и занятость памяти во время процесса невелики.
2.1 Информационное уведомление
2.1.1 Инструменты
Инструмент графика пламени: go-torch
Инструмент захвата пакетов https: ssldump
Инструмент измерения давления: ab
2.1.2 Конфигурация сервисных ресурсов
// 服务最高可用内存为2000Mi，最高可用CPU为4核
limits:
cpu: "4"
memory: 2000Mi
requests:
cpu: "2"
memory: 1000Mi
2.2 Стресс-тест на https
2.2.1 Перед нагрузочным тестированием
В случае очень небольшого количества подключений потребление производительности в основном приходится на сериализацию и десериализацию json. Как показано ниже:
2.2.2 Измерение давления
(1) Команда измерения давленияQps в это время составляет 500
ab -n 100000 -c 100 host
(2) График пламени Как видно из рисунка ниже, в настоящее время ущерб производительности json незначителен, в основном при полном рукопожатии https.
2.2.4 Проблемы
- 1. Почему рукопожатие https так сильно снижает производительность?
2.3 Стресс-тест во время http
После приведенного выше анализа мы примерно знаем потерю производительности, вызванную https.Теперь я меняю интерфейс сервиса на http и снова выполняю тест давления, чтобы увидеть, каков результат.
2.3.1 Перед стресс-тестированием
Как указано выше, производительность снижается для json.
2.3.2 Ссылка для стресс-теста: ссылка прямого доступа
(1) Команда измерения давленияQps на данный момент 8000
ab -n 100000 -c 100 host
(2) График пламени Как видно из рисунка ниже, ущерб производительности от json на данный момент незначителен, и производительность в основном расходуется на получение сетевых ресурсов, а также на некоторые системные вызовы: gc, poll и т.д.
Три, анализ производительности
Прежде чем продолжить чтение, я надеюсь, что у вас есть определенное понимание процесса рукопожатия https.
3.1 Почему потеря производительности https настолько серьезна?
3.1.1 Анализ причин
Полное рукопожатие https, основные моменты расчета:
- Асимметричный обмен ключами: используйте алгоритмы RSA, Diffie-Hellman, ECDHE и другие для генерации симметричных ключей с помощью высоконадежных алгоритмов генерации ключей.
- Симметричное шифрование и дешифрование: используйте сгенерированный выше симметричный ключ для шифрования и дешифрования сообщений.
- Проверка согласованности сообщения: к каждому зашифрованному фрагменту контента будет добавлено сообщение MAC, код аутентификации сообщения. Проще говоря, это безопасное вычисление хэша для контента, и получатель должен проверить MAC-код.
- Проверка подписи сертификата: клиент проверяет сертификат сервера
Из флейм-графа выше видно, что основное потребление производительности приходится на полное рукопожатие, то есть на процесс обмена асимметричным ключом.Давайте разберемся, почему этот процесс потребляет так много. Вот диаграмма производительности алгоритма обмена ключами ECDHE_RSA.
Видно, что ServerKeyExchange занимает 2,4 миллисекунды.ServerKeyExchange в основном подписывает параметры алгоритма обмена ключами, которые будут использоваться далее.Поскольку алгоритм RSA будет выполнять много операций, он потребляет много ресурсов процессора.
Используйте ssldump для захвата пакетов и убедитесь, что согласованный набор алгоритмов действительно следующий: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
3.1.2 Идеи по оптимизации
Есть две идеи оптимизации, одна — сократить время обмена ключами, а другая — уменьшить количество рукопожатий.
(1) Параллельные вычисления
Это сделано для сокращения времени рукопожатия.В настоящее время мы также используем карту ускорителя QAT онлайн для ускорения вычислений, а вычислительная часть поддерживается специальной картой аппаратного ускорителя для уменьшения объема вычислений ЦП. Этот раздел не расширяется, вы можете ознакомиться с подробностямиintel QAT
(2) Используйте идентификатор сеанса
После получения клиентского приветствия сервер сгенерирует sessionID и отправит его клиенту и кэширует его локально (это увеличит нагрузку на сервер).В последующем SSL-рукопожатии клиент может привести его при отправке клиентского приветствия, и сервер будет его искать.Описанию можно доверять. Но в настоящее время у всех нас есть несколько nginx, следующий запрос может не упасть на предыдущий nginx, поэтому мы можем использовать для поддержки распределенный кеш сеанса.
(3) Используйте сессионный билет
Перед завершением полного рукопожатия сервер отправит клиенту сессионный билет, который будет сохранен клиентом и может быть взят с вами во время следующего рукопожатия.Если сервер может правильно его расшифровать, значит, его можно повторно использован. Однако в сценарии с несколькими nginx несколько nginx должны использовать один и тот же закрытый ключ.
В-четвертых, другие моменты оптимизации
4.1 gc
На самом деле, судя по процессу стресс-тестирования во время http, gc составляет определенную долю в это время, и, отслеживая данные gc, мы можем знать, что gc достигает 70 раз в минуту в процессе стресс-тестирования, хотя каждый gc занимает очень короткое время. . В основном это связано с использованием большого количества временных объектов. Последующие оптимизации будут использовать объединение объектов и выбирать соответствующие параметры GOGC. Журнал gc показан ниже, если вам интересно, вы можете проанализировать его.