JMeter JDBC тестирование базы данных - максимальное ожидание (мс)

Question

Какова наилучшая практика для значения максимального ожидания (мс) в конфигурации соединения JDBC? JDBC

Я выполняю 2 типа тестов:

1. 20 циклов для каждого количества потоков - чтобы получить максимальную группу
2. 30 минут времени выполнения для каждого числа потоков - чтобы получить время ответа

С Max Wait = 10000ms я могу выполнить запрос JDBC с 10,20,30,40,60 и 80 Threads без ошибки. С Max Wait = 20000ms я могу пойти выше и выполнить с 100, 120, 140 Threads без ошибок. Это кажется логичным поведением.

Теперь вопрос. Могу ли я увеличить значение Max Wait по желанию? Это правильный способ, как получить больше результатов теста? Должен ли я прекратить тестирование и не увеличивать количество потоков, если в каком-либо отчете произошла ошибка? Я получил, например, 0,06% ошибок из 10000 образцов. Это остановка для моего тестирования? Благодарю.

Answer 1

Этот параметр соответствует параметру DBCP -> BasicDataSource -> maxWaitMillis в соответствии с документацией:

Максимальное количество миллисекунд, в течение которых пул будет ожидать (когда нет доступных подключений), чтобы соединение было возвращено, прежде чем выдать исключение, или -1, чтобы ждать бесконечно

Он должен соответствовать соответствующей настройке конфигурации базы данных вашего приложения. Если ваша цель - определить максимальную производительность - просто поставьте -1 там и таймаут будет отключен.

Относительно Это остановка для моего тестирования? - это зависит от множества факторов, таких как то, что делает приложение, чего вы пытаетесь достичь и какой тип тестирования проводится. Если вы тестируете базу данных, которая управляет работой атомной станции, то допустимым будет нулевой порог ошибки. И если это картинная галерея кошек, такой уровень ошибок можно считать приемлемым.

В большинстве случаев тестирование производительности делится на несколько тестовых выполнений, таких как:

1. Нагрузочное тестирование - установка системы под ожидаемую нагрузку, чтобы увидеть, способна ли она обрабатывать прогнозируемое количество пользователей
2. Испытание на замачивание - в основном то же самое, что и нагрузочное тестирование, но выдерживает нагрузку в течение длительного времени. Это позволяет обнаружить, например, утечки памяти
3. Стресс-тестирование - определение границ приложения, точек насыщения, узких мест и т. Д. Начиная с нулевой нагрузки и постепенно увеличивая ее до тех пор, пока она не перестанет упоминать максимальное количество пользователей, корреляцию других показателей, таких как время отклика, пропускная способность, частота ошибок и т. Д., С увеличение количества пользователей, проверка восстановления приложения после восстановления нагрузки и т. д.

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

Answer 2

Everything depends on what your requirements are and how you defined performance baseline.

Могу ли я увеличить значение Max Wait по желанию?Это правильный способ, как получить больше результатов теста?

• Если у вас все в порядке с более высоким временем отклика и функциональность должна работать, то вы можете сохранить максимальное время столько, сколько хотите. Но практически будет порог времени отклика (например, 2 секунды для выполнения транзакции входа в систему), который вы определяете как часть вашего SLA производительности или базового показателя производительности. Таким образом, хотя вы делаете ваши запросы успешными, увеличивая максимальное время, в конечном итоге это считается неудавшимся запросом из-за большого времени отклика (при превышении пороговых значений)

Примечание. Чем больше время отклика для операций с БД, тем больше время отклика для веб-приложений (или конечных пользователей).

Должен ли я прекратить тестирование и не увеличивать количество потоков, если в каком-либо отчете произошла ошибка?

• То же самое относится и к частоте появления ошибок. Если в соглашении об уровне обслуживания указано, что определенная доля ошибок согласована, то вы можете считать, что тест соответствует требованиям соглашения об уровне обслуживания или производительности, если фактическая частота ошибок меньше этой. Например: если в требованиях указано 0% ошибок, то 0,1% также считается ошибочным.

Это остановка для моего тестирования?

• Вы можете остановить тест в любой точке, которую вы хотите. Он полностью основан на том, какие метрики вы хотите захватить. Насколько мне известно, предлагается продолжать тестирование, пока оно не достигнет точки, при которой нет смысла продолжать тестирование, например, уровень ошибок достиг 99% и т. Д. Если вы получаете коэффициент ошибок 0,6%, я предлагаю продолжить с помощью теста можно узнать критическую точку системы, такую ​​как сбой сервера, время отклика, достигнутое до недопустимых значений, проблемы с памятью и т. д.

Ниже приведены некоторые хорошие ссылки:

1. https://www.nngroup.com/articles/response-times-3-important-limits/
2. http://calendar.perfplanet.com/2011/how-response-times-impact-business/
3. Разница между базовой линией и эталоном в производительности приложения
4. https://msdn.microsoft.com/en-us/library/ms190943.aspx
5. https://msdn.microsoft.com/en-us/library/bb924375.aspx
6. http://searchitchannel.techtarget.com/definition/service-level-agreement