JMETER 4. 0 |Распределенное нагрузочное тестирование JMeter |jp @ gc - группа степпинга |504 Время ожидания шлюза |Не HTTP код ответа |Утверждение не удалось

Question

Сценарий с учетом входа пользователя в систему-> Перейти к странице 01-> удерживать пользователя в течение 5 минут-> Выход пользователя из системы

Сценарий, как показано ниже:

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

Конфигурация потока обновления была сохранена следующим образом:

Для реализации этого сценария распределенная система была реализована следующим образом:

• Master (Моя собственная машина, 8 ГБ Ram и Core 2 Duo Processor)

• 2 подчиненных машины (8 ГБ оперативной памяти каждый и процессоры I7 и Core 2 Duo)

• Тема: jp @ gc - группа шаговых потоков

Сервер был настроен следующим образом:

• 2 Экземпляр EC2 (16 GB Ram каждый)
• 1 Балансировщик нагрузки
• 1 Экземпляр RDS

Примечание: Экземпляр автоматически масштабируется при 60% загрузки ЦП.

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

• 504 / Время ожидания шлюза
• Не HTTP-ответcode: java.net.SocketException / Non HTTP ответное сообщение: Сброс соединения
• Утверждение при выходе из системы не удалось

Может кто-нибудь помочь мне узнать, почему они появляются? когда я проверял, что там не появляется тайм-аут Load Balancer 504 / Gateway? Я пытался отследить эти ошибки, но не смог выяснить, почему они появляются вместе с двумя другими ошибками.Когда один и тот же сценарий выполняется для 10 пользователей, в режиме графического интерфейса не появляется ошибка.

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

Answer 1

Если проблема не возникает для 250 виртуальных пользователей, а возникает для 500 - это определенно узкое место , вызванное увеличением нагрузки, вам просто нужно выяснить причину.

1. Убедитесь, что Диспетчер DNS-кэша добавлен в ваш план тестирования, иначе вы можете столкнуться с ситуацией, когда загрузка идет только на один сервер
2. НастройкаМониторинг ваших экземпляров EC2, чтобы убедиться, что они имеют достаточный запас для работы с ЦП, ОЗУ, сетью и т. д. Для этого вы можете использовать Amazon CloudWatch или JMeter PerfMon Plugin .
3. Возможно, вы захотите перезапустить тест с инструментом профилирования с включенной телеметрией - так вы сможете увидеть, где приложение проводит большую часть времени
4. Проверьтеконфигурация серверов приложений, баз данных и т. д., как это может быть проблема конфигурации промежуточного программного обеспечения
5. Имейте в виду, что в соответствии с JMeter Best Practices всегда следует использовать последнюю версию JMeterверсия , поэтому рассмотрите возможность перехода на JMeter 5.0 (или любую последнюю версию, доступную на странице JMeter Downloads ) как можно скорее.