В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

QA — Load & Performance

2756 membersпожаловаться на группу
2021 March 16

АР

Александр Руснак... in QA — Load & Performance
Artem Astaxov
нагрузочная станция это генератор?
малое кол-во памяти это сколько , утилизация больше 90%?)
да это генератор нагрузки (единственное что я там заметил это большой процент использования ЦПУ во время тест - порядка 98 % ) но на мой взгялд это не могло быть причиной деградации по времени отклика.
источник
14:53пожаловаться#1

АР

Александр Руснак... in QA — Load & Performance
по идее с базой данных проблем тоже не должно быть
источник
14:53пожаловаться#2

АР

Александр Руснак... in QA — Load & Performance
так как запросы кэшируются и может быть высокое время только в начале теста
источник
14:53пожаловаться#3

АР

Александр Руснак... in QA — Load & Performance
я не знаю что тут еще можно псомтреть
источник
14:54пожаловаться#4

AA

Artem Astaxov in QA — Load & Performance
много имхо конечно, но если что то плохое с генератором нагрузки логично смотреть сколько реально запросов подавалось на систему или успешно хотя бы
просто по идеи более логична ситуация когда уровень нагрузки уменьшился если что то с генераторами
источник
14:55пожаловаться#5

AA

Artem Astaxov in QA — Load & Performance
если нагрузки выше подано было чем планировалось после определнного времени то и времена могли вырости
источник
14:55пожаловаться#6

АР

Александр Руснак... in QA — Load & Performance
Artem Astaxov
много имхо конечно, но если что то плохое с генератором нагрузки логично смотреть сколько реально запросов подавалось на систему или успешно хотя бы
просто по идеи более логична ситуация когда уровень нагрузки уменьшился если что то с генераторами
да это действительно логично, поэтому я в замешательстве. Ошибки в логах отсутствуют
источник
14:56пожаловаться#7

AA

Artem Astaxov in QA — Load & Performance
т.е как понимаю реальный уровень нагрузки вы не смотрели еще?
источник
14:57пожаловаться#8

АР

Александр Руснак... in QA — Load & Performance
Artem Astaxov
т.е как понимаю реальный уровень нагрузки вы не смотрели еще?
уточните, что понимается под "реальным уровнем"?
источник
14:58пожаловаться#9

AA

Artem Astaxov in QA — Load & Performance
у вас был какой то профиль или прогноз, вы по нему сделали сценарий на N операций в час/сек, верно?
вот тут может быть:
1. ошиблись и подается больше чем должно
2. из за проблем с генератором подается больше (ну в вашем случае логично что больше)
т.е реальный уровень это кол-во запросов которое пришло в конечную систему
источник
15:01пожаловаться#10

AA

Artem Astaxov in QA — Load & Performance
если это LR, то хотя бы качнуть равку и после выхода на стабильный уровень посчитать оп в час, все может быть банально же)
а проявиться не сразу такой просчет очень даже может
источник
15:02пожаловаться#11

АР

Александр Руснак... in QA — Load & Performance
интенсивности подачи запросов были рассчитаны и подобный тест с заданными характеристиками запускался ранее но деградации обнаружено не было (рпс не изменилось). Инструмент Jmeter
источник
15:05пожаловаться#12

АР

Александр Руснак... in QA — Load & Performance
мониторил и в графане и в CSV Jmeter
источник
15:07пожаловаться#13

А

Александр in QA — Load & Performance
БД не отбрасывайте сразу, возможно неоптимальные запросы накапливаются или впринципе есть какой-нибудь рекурсивный запрос. Ещё возможно фоновые задачи/отчеты какие-нибудь стакаются и тоже БД кладут. Т.е есть смысл ещё посмотреть на длительность выполнения запросов к БД. Например в awr отчете
источник
15:08пожаловаться#14

AA

Artem Astaxov in QA — Load & Performance
+ к фоновым задачам, было как то что во время теста запустилась очистка бд которая оч сильно нагружает бд
источник
15:11пожаловаться#15

AA

Artem Astaxov in QA — Load & Performance
как понимаю обнов, изменений в контуре (настройки, железо) тоже не было?
источник
15:12пожаловаться#16

А

Александр in QA — Load & Performance
Artem Astaxov
+ к фоновым задачам, было как то что во время теста запустилась очистка бд которая оч сильно нагружает бд
ага, если тест не повторяли то определенно ещё стоит повторить. Ибо бывает на времени завязаны задачки/кто-то решил там создать индексы в БД и ещё что-нибудь поделать)
источник
15:12пожаловаться#17

АР

Александр Руснак... in QA — Load & Performance
Александр
ага, если тест не повторяли то определенно ещё стоит повторить. Ибо бывает на времени завязаны задачки/кто-то решил там создать индексы в БД и ещё что-нибудь поделать)
Вот это очень вероятно
источник
15:13пожаловаться#18

АР

Александр Руснак... in QA — Load & Performance
Artem Astaxov
+ к фоновым задачам, было как то что во время теста запустилась очистка бд которая оч сильно нагружает бд
Были, но меня заверили, что они не значительные
источник
15:13пожаловаться#19

AA

Artem Astaxov in QA — Load & Performance
у нас забавнее было, это функция из нескольких релизов ранее, которую почему то после релиза не убрали)
источник
15:13пожаловаться#20