1

Я выполняю тест производительности в среде AWS с помощью инструмента jmeter. у нас есть кластер с автоматическим масштабированием, включенным и имеющим memcache session failover jars. мы используем ведущее ведомое устройство jmeter, поэтому мы не получаем данные ответа из файла JTL. Код ответа вернулся через 45 минут тестирования duartions: КодТестирование производительности в AWS с использованием инструмента jmeter возвращает ошибку 403 после продолжительности 45-60 минут duartion

Ответ: Сообщение 403 Ответ: Запрещенные

Пожалуйста, дайте мне знать, как решить эту проблему. Спасибо

После исследования большего числа я обнаружил, что причина - это сеансы переключения сеанса memcache, я обновил версию jars до 1.6.5, но все еще сталкиваюсь с той же проблемой. Пожалуйста, дайте мне знать, есть ли у кого-нибудь решение.

ответ

1

Вы используете ELB? Если да, читайте здесь: http://community.blazemeter.com/knowledgebase/articles/94060-testing-amazon-elbs

+0

1. Мы не назначаем каких-либо IP-ELB 2. мы имеем более одного экземпляра приложения, и мы включили липкость в УДР на протяжении 10 минут. Ниже приведены настройки, установленные в MSM

+0

если вы используя elb, этого можно ожидать. Чтобы получить достоверные результаты, вы должны увеличить трафик не более чем на 50% каждые 5 минут. Если вы заходите в ELB через запись DNS, установите TTL на 1 секунду и даже так, убедитесь, что ни один из инструментов в вашем кэше не использует кэширование DNS. – andreimarinescu

+0

Спасибо за ответ, на самом деле я отсутствовал на долгий отпуск, так что не получилось изменить, чтобы снова запустить тесты. Масштабирование - это показатели, которые вы упоминаете, одинаковы с нашей точки зрения. Я планирую запустить тест в ближайшее время, возможно, сегодня. можете ли вы уточнить, какое значение для TTL должно использовать 1 или 0. - -Dsun.net.inetaddr.ttl = 0. -Dsun.net.inetaddr.ttl = 1. спасибо в advnace, что вы действительно цените. –

1

Похоже, вы используете ELB. У ELB есть CNAME, прикрепленный к нему. AWS изменяет IP-адрес, прикрепленный к CNAME. Это происходит довольно часто.

Когда ваш тест начинается, JMeter выполняет поиск DNS для ELB CNAME. Ответ затем кэшируется. С этого момента тест отправляет трафик на IP-адрес, который был в ответе, который теперь кэшируется.

В результате, в какой-то момент (после изменения IP) вы тестируете старый IP-адрес, который теперь может принадлежать другому серверу или принадлежит серверу NO. Вероятно, именно поэтому вы получаете 403.

Для этого необходимо установить Cache TTL равным 0 (ноль). Это даст указание JMeter НЕ кэшировать ответ поиска DNS и всегда делать это снова (что в любом случае является более реалистичным). Вы должны добавить следующее в строку JMeter: -Dsun.net.inetaddr.ttl = 0.

Больше информации здесь: http://community.blazemeter.com/knowledgebase/articles/94060-testing-amazon-elbs

+0

Привет, Алон, я пробовал настройку, но все еще ошибка сохраняется, я установил -Dsun.net.inetaddr.ttl = 0, когда я запускаю тест jmeter. поэтому можете ли вы предоставить любое альтернативное решение. Это было бы очень полезно. По этой причине я не могу продолжать свой тест продолжительности. пожалуйста, заранее сообщите об этом! –

+0

Я также попытался настроить файл ttl в файле java.security и добавить во время запуска jtl из командной строки. Тем не менее, мы получаем ошибку 403.Я также посмотрел ELB Ip во время теста, но, похоже, он не меняет 'dig + short yourelbaddress a'. Не могли бы вы сообщить мне, если у вас есть альтернативное решение. –

+0

У меня есть источник корневого кода, это идентификатор JSESSION, который переключается на сервер, и когда один и тот же идентификатор сеанса переключается на другой сервер приложений, он выдает ошибку 403. Переход на LB Stickyness на более высокую длительность разрешает это, но я хочу знать корневой регистр. Почему включение сеанса на APP вызывает 403. Мы сохраняем сеанс в memcache. Если кто-то столкнулся с этой проблемой, пожалуйста, дайте мне знать. Заранее спасибо –