Kubernetes — это контейнерный оркестратор с открытым исходным кодом, созданный Google, который помогает запускать, управлять и масштабировать контейнерные приложения в облаке. Все основные облачные провайдеры (Google Cloud, AWS, Azure и т. Д.) Управляют платформами Kubernetes. В этой статье мы обсудим, как развернуть микросервис на основе Spring Boot с Google Cloud и провести тестирование производительности.
Вам также может понравиться руководство для начинающих Linode по Kubernetes .
Предпосылки
-
Maven , инструмент автоматизации сборки, предоставляемый Apache
-
Учетная запись Docker Hub
-
Установите gcloud-sdk
-
kubectl , интерфейс командной строки для запуска команд против Kubernetes
-
Система контроля версий Git
Вам также может понравиться: Микросервисная архитектура на Кубернетес
Шаг 1. Настройка учетной записи GCP
Перейдите по этой ссылке и войдите в свою учетную запись Google Cloud Platform. Если вы впервые в GCP, вы можете получить бесплатную пробную версию за 300 долларов. Вам нужно будет предоставить данные вашей кредитной карты, но с вас не будет взиматься плата, если вы не включите выставление счетов.
Подключитесь к своей учетной записи GCP удаленно
В вашем терминале выполните команду « sudo gcloud init.Это», и вам будет предложено выбрать конфигурацию. Выберите номер, соответствующий « Создать новую конфигурацию», и дайте ему имя по своему желанию. После предоставления имени вам будет предложено выбрать учетную запись, которую вы хотели бы использовать для выполнения операций для этой конфигурации. Выберите Войти с новой учетной записью . Следуйте сгенерированному URL и войдите в свою учетную запись GCP.
Выбор / Создание проекта
Если у вас уже есть проект, вы можете продолжить его. Если у вас его нет или вы хотите выполнить тесты в отдельном проекте, создайте его.
В строке меню , нажмите на Select-проекте. Если вы впервые используете GCP, иногда это может означать «Мой первый проект». Выберите New-project из всплывающего окна. Дайте вашему проекту имя и нажмите « Создать» .
Шаг 2: Создание кластера Kubernetes
Кластер является основой Google Kubernetes Engine. Все контейнерные приложения выполняются поверх кластера. Давайте теперь создадим кластер для нашего тестирования.
В меню навигации> Kubernetes Engine> Кластеры
Нажмите на Создать кластер . Выберите стандартный шаблон кластера или выберите подходящий шаблон в зависимости от вашей рабочей нагрузки. Дайте имя вашему кластеру, например, «тестирование производительности». Выберите us-central1-a в качестве зоны. В конфигурации пула по умолчанию в разделе Тип машины выберите n1-standard-1 . Это назначит каждому узлу 1 vCPU и 3,75 ГБ оперативной памяти.
Настройте доступ из командной строки kubectl, выполнив следующую команду:
Оболочка
1
# Командный доступ к кластеру Kuberenetes
2
get-credentials контейнерных кластеров gcloud [имя кластера] --zone [выбранная зона] --project [название проекта]
3
#Пример
4
тестирование производительности get-credentials для кластеров --zone us-central1-a --program springboot -performance-test
Теперь, когда мы выполнили настройку, давайте перейдем к тому, как развертывать микросервисы в Kubernetes.
Шаг 3: Тестирование приложения и создание файла Jar
В этом эксперименте мы будем использовать простой первичный веб-сервис, написанный на Spring Boot, который возвращает true или false для числа, которое мы предоставляем (в зависимости от того, простое число или нет) в качестве параметра запроса. Давайте теперь обсудим, как развернуть этот веб-сервис в Kubernetes. Репозиторий GitHub для веб-службы на основе загрузки Spring, который мы тестируем, можно найти здесь .
Вы можете протестировать собственное приложение или продолжить тестовое приложение. Чтобы продолжить, клонируйте репозиторий GitHub. Чтобы создать исполняемый файл jar, перейдите в каталог, где находится pom.xml, и выполните mvn clean install. Это создаст файл JAR в целевой директории. Чтобы проверить, имеет ли приложение желаемое поведение, отправьте запрос на localhost: 9000 / prime? Number = 90 через ваш браузер. Это должно показать ложь, так как число 90 не простое число. Кроме того, вы можете использовать команду curl для проверки работоспособности.
Оболочка
xxxxxxxxxx
1
# Клонировать репозиторий
2
git clone https://github.com/anushiya-thevapalan/springboot-test
3
# Перейдите в каталог, где находится файл pom.xml.
5
cd springboot-test / полный
6
# Построить проект
8
mvn clean install
9
# Запустите приложение
11
java -jar gs- activator -service-0.1.0.jar
12
# Убедитесь, что приложение работает.
14
curl localhost: 9000 / простое число = 90 .
Теперь, когда мы проверили функциональность приложения, давайте продолжим развертывание приложения в Kubernetes.
Шаг 4. Создание образа Docker для приложения
Docker - это платформа с открытым исходным кодом, разработанная для упрощения создания, развертывания и запуска приложений с использованием контейнеров. Контейнеры позволяют разработчикам упаковывать и отправлять приложение со всеми требованиями, такими как библиотеки и зависимости. Docker создает изображения автоматически, читая инструкции из Dockerfile. Dockerfile - это текстовый документ, который содержит все команды, которые пользователь может вызвать в командной строке для сборки изображения.
Dockerfile
1
ОТ ЯВЫ: 8
2
WORKDIR / дом
3
ДОБАВИТЬ gs-actator-service-0.1.0.jar
4
ЭКСПОЗИЦИЯ 9000
5
CMD java -jar gs-activator-service-0.1.0.jar
-
FROM - Dockerfile должен начинаться с
FROMинструкции. Это определяет базовую архитектуру ОС, используемую для создания образа. Некоторая форма базового изображения требуется для начала построения изображения. Поскольку наше приложение основано на версии 8 Java, мы используемjava:8в качестве базового изображения. -
WORKDIR - эта команда аналогична команде change directory (
cd), выполняемой в терминале. Он устанавливает рабочий каталог для любой команды, следующей за ним в Dockerfile. (В зависимости от ваших требований вы можете изменить рабочий каталог). -
ADD -
ADDкоманда позволяет вам копировать файлы из определенного места в образ Docker. Поскольку для запуска приложения требуется встроенный jar, мы добавляем его в образ Docker -
EXPOSE -
EXPOSEинструкция информирует Docker о том, что контейнер прослушивает указанные сетевые порты во время выполнения. Наше приложение работает в порту 9000, поэтому мы его указываем. -
CMD -
CMDкоманды обеспечивают параметры по умолчанию для выполнения контейнера. Команда, которую мы здесь предоставляем, запускает встроенное приложение.
Теперь, когда мы понимаем Dockerfile, давайте приступим к созданию образа Docker.
Оболочка
xxxxxxxxxx
1
# Построить образ докера
2
сборка docker --no-cache -t [имя учетной записи DockerHub] / [имя образа Docker] [расположение файла Docker]
3
#Пример:
4
сборка докера --no-cache -t anushiya / app.
Примечание . В конце команды есть точка. Точка в конце команды указывает на текущий каталог. После создания образа Docker переместите его в Docker Hub. Docker Hub - это крупнейший облачный репозиторий для контейнерных изображений. Этот репо используется для поиска и обмена изображениями контейнеров среди пользователей.
Если вы ранее не использовали Docker Hub, перейдите по ссылке, чтобы создать учетную запись пользователя. После его создания, войдите удаленно в свою учетную запись Docker Hub, а затем нажмите на изображение. Чтобы войти, выполните docker loginв своем терминале и введите имя пользователя и пароль при появлении запроса. После успешного входа в систему, отправьте свой образ Docker в Docker Hub.
Оболочка
xxxxxxxxxx
1
# удалить логин в Docker hub
2
вход в докер
3
# перенести образ докера в концентратор Docker
4
docker push [имя учетной записи Docker Hub] / [имя развертывания]: [версия]
5
#Пример:
6
Докер Пуш Анушия / приложение: последний Докер Пуш Анушия / приложение: v1
Мы успешно создали образ Docker нашего приложения и отправили его в Docker Hub. Теперь давайте создадим размещение в Kubernetes.
Шаг 5. Создание развертывания Kubernetes для приложения
На этом шаге мы опишем, как развернуть приложение Spring Boot в Kubernetes. Желаемое состояние для приложения описано в файле развертывания YAML. Файл передается мастеру Kubernetes, и мастер создает объект развертывания. Контроллер развертывания отвечает за поддержание желаемого состояния, описанного в файле YAML развертывания. Он выполняет рутинные задачи, чтобы обеспечить поддержание желаемого состояния.
YAML
xxxxxxxxxx
1
# app.yaml
2
apiVersion apps / v1
3
вид развертывание
4
метаданные
5
название springboot-app
6
этикетки
7
приложение Springboot-приложение
8
спецификация
9
Реплики 1
10
селектор
11
matchLabels
12
приложение Springboot-приложение
13
шаблон
14
метаданные
15
этикетки
16
приложение Springboot-приложение
17
спецификация
18
контейнеры
19
название springboot-app
20
изображение anushiya / app последнее
21
ресурсы
22
пределы
23
процессор "100м"
24
запросы
25
процессор "100м"
26
порты
27
containerPort 9000
В приведенном выше примере
-
Развертывание с именем springboot-app создается, обозначается полем метаданные: имя .
-
Развертывание создает один реплицированный Pod, указанный полем replicas.
-
Шаблон модуля Pod или поле spec: template указывает, что его модули имеют название app: springboot-app .
-
Спецификация шаблона Pod или поле template: spec указывает на то, что модули запускают один контейнер, springboot -app , который запускает образ Docker Hub anushiya / app (ранее созданный образ Docker) в последней версии.
-
В спецификации шаблона Pod ресурсы: пределы и ресурсы: запросы указывают максимальное и минимальное распределение ресурсов для контейнера.
-
Развертывание открывает порт 9000 для использования модулями.
Примените созданный файл YAML для создания развертывания.
Оболочка
xxxxxxxxxx
1
kubectl применить -f путь / к / файлу /
2
#Пример
3
kubectl применить -f deployments / app / app.yaml
Сервис Kubernetes - это абстрактный способ представить приложение, работающее на наборе модулей, как сетевой сервис. Чтобы сделать развернутое приложение доступным через кластер, мы выставляем его с помощью объекта Service.
YAML
xxxxxxxxxx
1
# Приложение-svc.yaml
2
apiVersion v1
3
вид Сервис
4
метаданные
5
имя springboot-app-svc
6
спецификация
7
порты
8
название прайм-сервис
9
порт 80
10
targetPort 9000
11
селектор
12
приложение Springboot-приложение
13
Тип NodePort
-
Эта спецификация создает новый объект Service с именем « springboot-app-svc ».
-
Сервис может сопоставить любой входящий порт с targetPort. В этом случае порт 9000 контейнера отображается на порт 80.
-
Селектор spec: указывает, что Pods, помеченные springboot-app , обслуживаются объектом Service.
-
Тип: NodePort указывает тип объекта обслуживания.
-
Примените Service YAML для создания объекта Service.
Оболочка
xxxxxxxxxx
1
kubectl применить -f путь / к / файлу /
2
#Пример
3
kubectl применить -f развертывания / app-svc.yaml
Отправляя запрос curl, проверьте работоспособность приложения.
Оболочка
xxxxxxxxxx
1
# Для отправки запроса можно использовать IP-адрес сервиса или название сервиса
2
curl springboot-app-svc: 9000 / простое число = 71
Шаг 6: Создание образа Docker для JMeter
Для тестирования производительности приложения Spring Boot мы используем JMeter в качестве клиента нагрузочного тестирования. Для развертывания JMeter нам нужно сначала создать образ Docker. Ниже приведен Dockerfile для JMeter. Обратите внимание, что мы устанавливаем Python, поскольку мы используем Python для обработки данных о производительности.
Dockerfile
xxxxxxxxxx
1
ОТ анушия / jmeter-плагины: v1
2
ДОБАВИТЬ bash / home / kubernetes-performance / bash
4
ДОБАВИТЬ банку / домашний / kubernetes-performance / баночка
5
ДОБАВИТЬ jmx / home / kubernetes-performance / jmx
6
ДОБАВИТЬ python / home / kubernetes-performance / python
7
WORKDIR / home / kubernetes-перформанс / bash
9
RUN chmod + x start_performance_test.sh
11
RUN apt-get update && apt-get install python3.5 -y
13
RUN apt-get установить python-pip -y
14
RUN pip установить расписание numy запросов
-
Используется базовый образ анушия / jmeter-plugins версии v1 . Это изображение включает версию 5.1 JMeter и ее плагины.
-
Необходимые файлы добавляются в контейнер Docker с помощью команды ADD .
- WORKDIR установлен в / главная / kubernetes производительность / Баш.
- Разрешение на выполнение задается для файла сценария start_performance_test.sh .
- Python версии 3.5 устанавливается с помощью
apt-getкоманды. - Необходимые библиотеки Python установлены.
Давайте теперь создадим образ Docker и отправим его в Docker Hub.
Примечание. Файлы, добавленные в образ Docker в приведенном выше Dockerfile, требуют изменений, если вы хотите выполнить тесты. Мы будем обсуждать это в следующих шагах.
Оболочка
xxxxxxxxxx
1
# Построить образ Docker
2
сборка докера --no-cache -t anushiya / perf-test: v1.
3
# перенесите изображение в Docker Hub
4
докер пуш анушия / перф-тест: v1
Шаг 7. Создание постоянных томов для хранения данных о производительности
Результаты тестов производительности должны храниться постоянно. Здесь мы используем объем хоста для хранения результатов теста. Для этой цели вы можете использовать Cloud Filestore или любой другой постоянный том хранения.
Чтобы получить подробную информацию об узлах в вашем кластере, выполните приведенную ниже команду.
Оболочка
xxxxxxxxxx
1
# Получить узлы
2
kubectl получить узлы
3
#Вывод
4
НАЗВАНИЕ СТАТУСА РОЛЫ ВОЗРАСТА
5
GKE эффективность тестирования по умолчанию бассейн-b6e4d476-78zn Ready <нет> 11m v1.13.11-gke.14
6
GKE эффективность тестирования по умолчанию бассейн-b6e4d476-kfn8 Ready <нет> 11m v1.13.11-gke.14
7
GKE эффективность тестирования по умолчанию бассейн-b6e4d476-n538 Ready <нет> 11m v1.13.11-gke.14
8
Чтобы создать хост-том, зайдите в любой из вышеперечисленных узлов.
xxxxxxxxxx
1
#ssh в узел
2
sudo gcloud beta compute --project "[название проекта]" ssh --zone "[зона]" "[имя узла]"
3
#пример
4
sudo gcloud beta compute --project "тестирование производительности" ssh --zone "us-central1-a" "gke-performance-testing-default-pool-b6e4d476-78zn"
5
Создайте каталог для монтирования данных.
sudo mkdir /mnt/data/results
Теперь создайте постоянный том.
xxxxxxxxxx
1
apiVersion v1
2
вид PersistentVolume
3
метаданные
4
Название PV-том
5
этикетки
6
тип местный
7
спецификация
8
storageClassName ручной
9
емкость
10
хранение ги
11
accessModes
12
ReadWriteOnce
13
hostPath
14
путь "/ mnt / data / results"
Создайте постоянную заявку на объем.
YAML
x
1
apiVersion v1
2
вид PersistentVolumeClaim
3
метаданные
4
имя пв-претензия
5
спецификация
6
storageClassName ручной
7
accessModes
8
ReadWriteOnce
9
ресурсы
10
запросы
11
хранение 6Gi
После выполнения тестов результаты будут доступны в каталоге mnt / data / results, который мы создали выше.
Шаг 8. Создание задания по тестированию производительности и его развертывание
Используя образ Docker, который мы создали выше для JMeter, мы создадим задание для выполнения нагрузочного тестирования.
Основная функция задания - создать один или несколько модулей и отслеживать их успех. Они гарантируют, что указанное количество модулей выполнено до завершения. Когда указанное количество успешных модулей завершено, задание считается выполненным.
YAML
x
1
apiVersion партия / v1
2
вид работа
3
метаданные
4
название перф-тест
5
спецификация
6
шаблон
7
спецификация
8
контейнеры
9
название perf-test
10
изображение anushiya / k8-performance-test v1
11
imagePullPolicy всегда
12
команда "bash" "start_performance_test.sh"
13
volumeMounts
14
mountPath "/ home / jmeter / results"
15
Название PV-хранилище
16
restartPolicy никогда
17
объемы
18
имя PV-хранилище
19
persistentVolumeClaim
20
RequestName PV -претензия
21
backoffLimit 4
-
Создается задание с именем «perf-test», указанное в поле метаданные : имя .
-
Спецификация шаблона задания или поле template: spec указывает, что задание запускает один контейнер, perf-test, который запускает образ anushiya / perf-test: v1 .
-
В volumeMounts: mountPath определяет смонтированные тома.
-
В nodeSelector Выбирает узел , в котором Работа будет работать. Выполните
kubectl get nodes --show-labelsкоманду, чтобы получить метки каждого узла. В списке меток найдите тот, у которого есть ключ kubernetes.io/hostname, и замените значение в приведенном выше YAML. -
Спецификации: объемы указывает требование объема мы используем.
Примените файл YAML, чтобы начать тест производительности.
Оболочка
xxxxxxxxxx
1
kubectl применить -f развертывания / perf-test.yaml
Шаг 9. Сбор метрик из API мониторинга Stackdriver
Мониторинг статистики во время теста производительности важен, так как он позволяет нам понять поведение различных параметров (например, использование ресурсов) во время теста производительности. В этой статье мы используем API мониторинга Stackdriver для получения статистики производительности. ( Примечание . Метрики будут собираться при выполнении тестов производительности. Это предварительные шаги, которые необходимо выполнить).
Во-первых, мы должны включить API мониторинга Stackdriver . Чтобы включить, нажмите Меню навигации > API и сервисы > Панель инструментов. Найдите Stackdriver в строке поиска . Если API не включен, нажмите Включить.
Для отправки запросов API во время выполнения наших тестов нам требуются следующие учетные данные.
-
Ключ API - ключ интерфейса прикладного программирования (ключ API) - это уникальный идентификатор, используемый для аутентификации пользователя, разработчика или вызывающей программы в API.
-
OAuth 2.0 токен доступа - токен доступа представляет авторизацию определенного приложения для доступа к определенным частям данных пользователя.
Создать ключ API
Чтобы создать ключ API, откройте меню навигации > API и службы > учетные данные . Нажмите на Создать учетные данные . Выберите ключ API в раскрывающемся меню. Это сгенерирует ключ API.
Создать OAuth2.0 токен доступа
Чтобы создать маркер доступа, во- первых, мы требуем ID клиента и секрет клиента. В меню навигации > API и сервисы > учетные данные. Нажмите на Создать учетные данные. Выберите идентификатор клиента OAuth в раскрывающемся меню. Выберите Другое для Типа приложения. Укажите желаемое имя для идентификатора клиента (например, OAuth client 1) и нажмите « Создать».
Теперь, когда мы создали идентификатор клиента и секрет клиента, мы будем использовать их для создания токена доступа. Вы можете использовать много способов для создания токена доступа. Мы используем Почтальон, чтобы создать его.
Запустить Почтальон. Создайте новый запрос, нажав на значок (+) . Выберите вкладку Авторизация . На вкладке Авторизация выберите OAuth2.0 в раскрывающемся меню «Тип». Нажмите на Получить новый токен доступа .
Заполните всплывающее диалоговое окно следующей информацией и нажмите « Запросить токен».
-
Имя токена: gcp_auth_token (вы можете дать любое имя, какое пожелаете)
-
Тип гранта: Код авторизации
-
URL авторизации: https://accounts.google.com/o/oauth2/auth
-
URL токена доступа: https://oauth2.googleapis.com/token
-
Идентификатор клиента: [Идентификатор клиента, созданный на предыдущих этапах]
-
Секрет клиента: [Секрет клиента, сгенерированный на вышеуказанных этапах]
-
Область действия: Добавьте следующие URL, разделенные пробелом
-
https://www.googleapis.com/auth/cloud-platform
-
https://www.googleapis.com/auth/monitoring
-
https://www.googleapis.com/auth/monitoring.read
-
-
Аутентификация клиента: отправка в виде основного заголовка аутентификации
Вам будет предложено войти в свою учетную запись Google. Укажите учетные данные для входа. Токен доступа будет возвращен после аутентификации.
Шаг 10: скрипт сбора метрик
Следующий файл скрипта Python отвечает за сбор метрик из API мониторинга Stackdriver. Этот скрипт вызывается в конце выполнения тестов.
-
Сначала мы импортируем все необходимые библиотеки.
-
Далее мы импортируем все функции Python из других файлов Python. Например,
-
from container_cpu_utilization_stats import * - Импортирует все функции Python из файла container_cpu_utilization_stats.py
-
-
Переменные start_time , end_time и size назначаются с параметрами, полученными при вызове файла Python. Это так называемые системные аргументы. Период сбора метрик - это время между start_time и end_time .
Давайте теперь попробуем понять
query_metrics()функции -
И start_time, и end_time кодируются в процентах URL. Эта кодировка необходима для определения URL-адреса для отправки запроса API.
-
В файле container_metrics_list содержится список метрик, которые мы планируем отслеживать и собирать. Исходя из ваших требований, вы можете добавить любое количество метрик в этот список, как вы пожелаете. Полный список метрик GCP можно найти здесь .
-
Для отправки запроса API и сбора метрик нам требуется ключ API и токен доступа. Мы сгенерировали их оба на вышеуказанных этапах.
Замените [ACCESS_TOKEN] на созданный вами токен доступа. Также в конце URL замените [API_KEY] на сгенерированный ключ API.
-
Мы отправляем запрос API с использованием библиотеки запросов и записываем ответ.
-
Для каждого показателя в container_metrics_list мы выполняем запрос API и регистрируем ответ.
-
Ответ JSON огромен, и мы не требуем от него всех подробностей. Поэтому мы обрабатываем файл JSON для извлечения только необходимой информации. (Вы можете найти все эти файлы в хранилище).
Шаг 11. Подготовка сценариев тестирования производительности
Создание JMX
-
Открыть JMeter
Открыть JMeter
-
Щелкните правой кнопкой мыши План тестирования > Темы (пользователи) > Группа потоков.
Группа потоков
-
Заполните диалоговое окно следующими параметрами
-
Имя: группа1
-
Количество потоков (пользователей): $ {__ P (group1.threads)}
-
Продолжительность (секунды): $ {__ P (group1.seconds)}
конфигурация
-
-
Щелкните правой кнопкой мыши на group1 > Добавить > Sampler > HTTP Request
HTTP-запрос
-
Заполните диалоговое окно следующими параметрами:
-
Имя: HTTP-запрос
-
Имя сервера или IP: $ {__ P (group1.host)}
-
Номер порта: $ {__ P (group1.port)}
-
Метод: ПОЛУЧИТЬ
-
Путь: /$ndom__P(group1.endpoint)}
-
Нажмите кнопку Добавить в нижней части окна.
-
Имя: $ {__ P (group1.param)}
-
Значение: $ {__ P (group1.data)}
-
Тип контента: текст / обычный
-
Отметьте Включить равные
-
-
-
Сохраните файл как jmeter.jmx
Шаг 12: Автоматизация тестов производительности
При выполнении тестов производительности нам нужно запускать эти тесты для ряда сценариев рабочей нагрузки (например, уровней параллелизма, размеров кучи, размеров сообщений и т. Д.). Выполнение тестов вручную для каждого из этих сценариев занимает много времени и может привести к ошибкам. Поэтому важно автоматизировать тесты производительности перед их выполнением. Мы автоматизируем наши тесты производительности с помощью сценария оболочки: start_performance_test.sh . Давайте теперь объясним основные функции этого скрипта.
-
Сначала мы определяем IP-адрес внутреннего хоста. Это IP-адрес развернутой основной службы (т. Е. Приложения Spring Boot, которое мы развернули выше). Вы можете использовать имя службы, т.е. spring-boot-app-svc, или указать IP-адрес.
-
Затем мы инициализируем продолжительность теста и время прогрева. run_time_length_seconds - общее время выполнения теста производительности. Как следует из названия, это должно быть дано в считанные секунды.
-
Пути к нужным каталогам и именам файлов определены.
-
Затем мы указываем конфигурации, на которых мы проводим тесты. Мы провели тесты с двумя разными простыми числами (521, 100003) для разного параллелизма (1, 10, 50, 100, 500).
-
Для записи результатов теста создаются отдельные каталоги. Файл назван с установленными конфигурациями, чтобы его было легко идентифицировать.
-
Основная команда для запуска файла JMX следующая.
Оболочка
xxxxxxxxxx
1
jmeter -n -t $ {jmeter_jmx_file_root} /jmeter.jmx -l $ {jtl_report_location} /results.jtl
-n : Он инструктирует JMeter работать в режиме без графического интерфейса
-t : Имя файла JMX, который содержит План тестирования
-l : Имя файла JTL (текстовые журналы JMeter) для регистрации результатов
. Остальные параметры, которые начинаются с -Jgroup1 , передаются в файл JMX, который мы создано выше. Мы смотрели на эти параметры, когда создавали файл JMX.
-
Начальные n минут jtls, собранных JMeter, удаляются с помощью JTL-разветвителя, разработанного WSO2 . Эти данные удаляются, так как Java выполняет JIT (Just In Time) компиляцию. Чтобы получить стабильные результаты производительности, первоначальные результаты удаляются
-
Затем мы обрабатываем результаты теста, собранные JMeter, используя скрипт Python, и записываем сводку в файл CSV.
-
Наконец, мы вызываем скрипт Python, отвечающий за сбор и обработку метрик из API мониторинга Stackdriver.
Шаг 13: Анализ результатов деятельности
На следующих рисунках показано поведение TPS по сравнению с параллелизмом и средней задержкой по сравнению с параллелизмом для простого числа 521.
Давайте теперь посмотрим на показатели, которые мы собрали из Stackdriver Monitoring API. Хотя мы собрали список метрик, давайте проанализируем метрику использования ЦП. На рисунке ниже показано, как загрузка ЦП меняется со временем.
Дальнейшее чтение
Привод пружинной загрузки: полное руководство
Разработка приложения Spring Boot для кластера Kubernetes (часть 1)