Size: a a a

QA — Load & Performance

2021 October 09

A

Anna in QA — Load & Performance
как пришли к такому решению? оно выглядит необычно. про связку с тг и потоки расскажешь?
источник

VS

Vladimir Sitnikov in QA — Load & Performance
Пришли исторически. Наверное, началось всё с того, что проще сделать запускатель на shell/python/далее по списку, чем вкрутить полноценную фичу в jmeter.
источник

A

Anna in QA — Load & Performance
вот у меня обратный путь получился. я напоролась на фичу и не могу теперь с нее слезть
источник

A

Anna in QA — Load & Performance
опять же, умножение жметров умножает xmx, что может выбрать память хоста
источник

VS

Vladimir Sitnikov in QA — Load & Performance
Про потоки тоже в докладе было: если знаем, что с системой будет работать 100 пользователей, то ставим 100 потоков. Либо же ставим "чтобы хватило", а нагрузка всё равно через precise. Но, честно говоря, команд у нас много и не факт что именно так везде :)
источник

A

Anna in QA — Load & Performance
так я про банковскую финашку спрашиваю, там нет пользователей
источник

VS

Vladimir Sitnikov in QA — Load & Performance
Если нет, то наугад ставим
источник

A

Anna in QA — Load & Performance
если надо потестить, какие ответы будут на 500 тпс при какой-то настройке системы, ответы которой скачут, сколько потоков поставишь? если "чтоб хватило", то может и несколько тыщ получиться, выглядит бредово немножко
источник

A

Anna in QA — Load & Performance
пока так и живём, но есть дичь на графиках, которая очень похожа на тред-свичи
источник

A

Anna in QA — Load & Performance
ответы скачут к примеру от 1мс до 5сек
источник

VS

Vladimir Sitnikov in QA — Load & Performance
Ну, как бы закон Литтла: количество нужных тредов точно равно среднему времени работы, умноженному на rps. Если 500rps, и в среднем работает за 100мс, то должно быть достаточно 50 тредов. Сколько у вас там среднее получается?
источник

A

Anna in QA — Load & Performance
ну допустим 200мс. если потоков не хватит, то в момент долгих ответов нагрузка просядет
источник

VS

Vladimir Sitnikov in QA — Load & Performance
50 и 100 тредов должно быть норм, если они ждут большую часть времени
источник

A

Anna in QA — Load & Performance
для 500 тпс?
источник

VS

Vladimir Sitnikov in QA — Load & Performance
Ну, да
источник

A

Anna in QA — Load & Performance
и как поддержится нагрузка в 500 тпс сотней потоков в ту секунду, когда система задумалась? они все  будут ждать ответа, а пулять некому
источник

VS

Vladimir Sitnikov in QA — Load & Performance
Правильные вещи говорите. Так мы и coordinated omisson вспомним. Или намекаете, что тредами в целом неправильно тестировать?

Я бы предложил строить график времени отклика от времени и график интенсивности запросов от времени и смотреть хватило ли
источник

S

Sergey in QA — Load & Performance
Только не 50 трендов, а 51
источник

VS

Vladimir Sitnikov in QA — Load & Performance
Почему 51?
источник

S

Sergey in QA — Load & Performance
По математике СМО если скорость потока=скорости обработки - копится бесконечная очередь
источник