Пользователи, отклики, циклы, как правильно записывать
#21
Отправлено 23 октября 2013 - 06:55
еще один вопросик, если вам не сложно ответить?)
мы нагрузочным тестированием не занимались раньше и понятия не имеем, как сохранять отчеты...вернее как сохранить их в проге знаем..
но можно ли данные таблицы, графика перенести в какую другую программу, может ехсель, ворд.
Вот я например проведу тестирование, мне начальнику надо предоставить результаты., Просто вкрадце в ворде описать результаты, выводы, проблему и т.п, вставить график????
или обычно еще предаставляются файлы с проги.
"Не сломал - значит, не старался!"
#22
Отправлено 23 октября 2013 - 08:58
А лучше жметром записывать логи, а по логам строить графики. Существует много библиотек/софта, строящих графики. Тот же gnuplot, например.
#23
Отправлено 29 октября 2013 - 19:22
#24
Отправлено 05 декабря 2013 - 05:47
Если я тестирую на небольшое количество пользователей, и в этот момет лажу по приложению, страницы грузятся как обычно, быстро.
Если же я тестирую на большое количество пользователей, 500, 1000, то страницы еле грузятся, иногда появляется страница с ошибкой..Значит ли это что есть ошибка?
"Не сломал - значит, не старался!"
#25
Отправлено 05 декабря 2013 - 06:19
Прикрепленные файлы
"Не сломал - значит, не старался!"
#26
Отправлено 05 декабря 2013 - 06:36
Прикрепленные файлы
"Не сломал - значит, не старался!"
#27
Отправлено 05 декабря 2013 - 09:35
Listener -> Aggregate Report.Откуда берутся значения Производительность и время отклика?
Можно по логам Jmeter считать самостоятельно.
#28
Отправлено 05 декабря 2013 - 10:11
Listener -> Aggregate Report.
Откуда берутся значения Производительность и время отклика?
Можно по логам Jmeter считать самостоятельно.
А с какой колонки берутся значения? В Aggregate Report.
"Не сломал - значит, не старался!"
#29
Отправлено 05 декабря 2013 - 13:32
max - максимальное время ответа в миллисекундах
average - среднее время ответа в миллисекундах
метрики таймингов не очень полезные в контексте нагрузочного тестирования, лучше используйте процентили (90% line, например. Но эта метрика мало кому подходит по требованиям SLA. Намного более полезны 95%-99% line)
#30
Отправлено 05 декабря 2013 - 13:54
Кстати, крутой отчёт. 147 rps в 0 потоков.Откуда берутся значения Производительность и время отклика?
#31
Отправлено 06 декабря 2013 - 13:02
этот отчет я в нете нашла.Кстати, крутой отчёт. 147 rps в 0 потоков.
Откуда берутся значения Производительность и время отклика?
Пожалуйста, просветите, как throughput (производительность) посчитать. Я выписала чисто значения из колонки throughput, в сек. И по этим результатам она растет, того же быть не может.
Прикрепленные файлы
"Не сломал - значит, не старался!"
#32
Отправлено 16 декабря 2013 - 19:05
И, почему же не может такого быть? Количество запросов же увеличивается, и до какого-то момента приложение отлично справляется с такой нагрузкой.
#33
Отправлено 24 декабря 2013 - 08:23
Да, все верно сделали. Производительность и есть значение колонки throughput в Aggregate report
И, почему же не может такого быть? Количество запросов же увеличивается, и до какого-то момента приложение отлично справляется с такой нагрузкой.
меня смущало, то что вычитала, что значение берется с колонки throughput, но не записывается в виде в котором есть, а высчитывается. Вот это меня и заинтересовало, как высчитывать?!!)
"Не сломал - значит, не старался!"
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных