Перейти к содержимому

Подготовка к сертификации ISTQB FL
онлайн, начало 10 августа
Тестирование REST API
онлайн, начало 10 августа
Программирование на Python для тестировщиков
онлайн, начало 14 августа
Тестирование без требований
онлайн, начало 17 августа
Фотография

Пытаюсь подобрать инструмент - взываю к коллективному разуму

нагрузочное тестирование

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 5

#1 akaars

akaars

    Новый участник

  • Members
  • Pip
  • 64 сообщений


Отправлено 09 июля 2017 - 05:15

Всем доброго времени суток!

Опишу тест:

Есть HTTP-сервер, который принимает POST запросы.

Есть 6000 репортеров, объединенных в группы по сколько-то объектов (почему это важно - объясню дальше), каждый из которых создаёт 3 разных POST-запроса. Каждый из этих POST-ов отсылается раз в пол-минуты. Т.е. упрощённо говоря, за минуту должно уйти на сервер 36000 POST-ов. Причём не одной волной, а именно так, "размазано во времени". В среднем, соответственно, получается нагрузка на сервер в 600 rps.

Каждый из 6000 репортеров, как я и сказал, генерирует 3 вида отчётов с частотой 30 секунд для каждого из отчётов. Т.е. это может быть одновременная отсылка всех 3-х отчетов каждые 30 секунд, или же отправка одного отчёта, через 10 секунд - другого, ещё через десять - 3-го - и через 10 секунд опять всё по-новой. Главное, чтобы каждый отчёт отсылался раз в 30 секунд. Для каждого отчёта нужно генерить свой токен, который подставляется в URI. C некорректным токеном POST не пройдёт.

Теперь самое веселое: некоторые из этих отчётов должны быть парными. Т.е. если для одного из репортеров из группы Х выбирается репортер из группы У (зависимость групп известна заранее, она однозначна, т.е. группа Х всегда будет соответсвовать Y и никогда Z. Количество репортеров в группах одинаковое, поэтому для простоты можно всегда сопоставлять репортер из группы Х репортеру из группы У например по индексу).

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

 

Я сталкиваюсь с такой задачей в первый раз. В начале было накропал скрипт на питоне, наивно подумав, что всё будет просто, но оказалось, что нет :) Я умею генерировать необходимые репорты для всех репортеров, но не умею отсылать их красиво с заданной частотой :(

Прошу совета в подборе инструмента. Плиииз :)


  • 0

#2 akaars

akaars

    Новый участник

  • Members
  • Pip
  • 64 сообщений


Отправлено 09 июля 2017 - 14:09

Да, ещё такой момент, чтобы прояснить проблему, с которой я столкнулся:

изначально для тестов использовался Jmeter, который создавал на каждый объект по 3 треда (для каждого вида отчёта). С одной виртуалки мы запускали Jmeter для 2000 объектов, соответственно, получалось 6000 тредов, которые, конечно, грузили машину, но бежали независимо друг от друга: каждый тред слал отчёт раз в 30 секунд и не переживал, что ответ от сервера мог прийти через, скажем, 10 секунд.

Когдя я писал свой скрипт, то наивно подумал, что ответы будут приходить быстро, но фиг там. Поэтому получается, что послать все отчёты я, возможно, могу за 30 секунд. Но вместе с ождиданием ответа это может взять и 40-50 секунд. А тогда я уже не успеваю начать заново рассылку отчётов :(

Хмм, может, запускать второй тред по истечени 30 секунд с начала предыдущего, не дожидаясь его окончания?


  • 0

#3 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 09 июля 2017 - 17:24

а причина ухода с JMeter? может там просто надо и сделать генерацию токенов и "парные отчёты"? 

 

а "парные" отчёты - у разных групп пользователей будут похожие или одни и те же параметры для отчётов, вот и вся "парность", вроде должно быть просто? типа:

группа репортёры1: аккаунт1, клиент1, за текущий месяц

группа репортёры2: аккаунт1, клиент1, за прошедший месяц

 

?

 

тем более что параметры ясны до начала тестов, значит не нужно их генерировать "на лету"

 

насчёт тредов и "успевания отсылать" и "ожидания ответов": 

репортёры, если они люди конечно, обычно работают синхронно - человек запрашивает отчёт и сидит ждёт пока отчёт загрузится. вроде ничего усложнять не надо


  • 1

#4 akaars

akaars

    Новый участник

  • Members
  • Pip
  • 64 сообщений


Отправлено 09 июля 2017 - 18:40

а причина ухода с JMeter? может там просто надо и сделать генерацию токенов и "парные отчёты"? 

Причин несколько. На самом деле основная: я совершенно не знаю Java :) Учить, конечно, надо, но сроки поджимали :( А написание скрипта на питоне прекрасно укладывалось в немаленький фреймворк, который я к тому времени успел наворотить. Т.е. функционально мне было это делать очень легко и удобно. Если бы не проблемы выше... :)

 

Генерация токенов в Jmeter была. Основной мой затык был в "парных" отчётах. Там всё не настолько тривиально. Причём настолько "не настолько", что мой коллега, который в своё время писал предыдущие тесты под Jmeter, долго смотрел в требования, чесал голову и в итоге сказал, что ему надо будет как минимум 3 дня на написание. Этих трёх дней у нас не было :(


  • 0

#5 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 09 июля 2017 - 19:15

кстати в JMeter не Java, а Beanshell, с которого можно исполнять и код на джаве, и скрипты на пайтоне

 

например
https://stackoverflo...request-sampler


  • 2

#6 akaars

akaars

    Новый участник

  • Members
  • Pip
  • 64 сообщений


Отправлено 09 июля 2017 - 19:21

Хм. Я должен это обдумать. Спасибо :)


  • 0


Тестирование производительности (JMeter)
онлайн
Тестирование удобства использования
онлайн
Тестирование REST API
онлайн
Тестирование веб-приложений 2.0
онлайн




Темы с аналогичным тегами нагрузочное тестирование

Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале