#performance #oracle #stored-procedures #plsql
#Производительность #Oracle #хранимые процедуры #plsql
Вопрос:
Я знаю utplsql для модульного тестирования, есть ли способ, которым я мог бы использовать это в цикле для нагрузочного тестирования моей хранимой процедуры?
Я не хочу использовать JMeter или просматривать какие-либо драйверы JDBC — просто пытаюсь проанализировать производительность ванильного сохраненного процесса
Комментарии:
1. Здесь есть интересная статья: dba-oracle.com/t_benchmark_testing.htm
2. Что не так с JDBC? Накладные расходы при вызове хранимой процедуры должны быть незначительными (по сравнению с временем выполнения процедуры)
3. @a_horse_with_no_name: у нас уже есть некоторые результаты теста JDBC, мы хотим разделить их только на DB. Поможет ли включение ОТЛАДКИ в драйвере Oracle с фактическим затрачиваемым временем?
Ответ №1:
Я не думаю, что инструмент модульного тестирования — это правильный подход, потому что вы на самом деле не делаете заявлений о функциональности. С помощью нагрузочного теста вы хотите знать, как выполняется процедура с большим объемом данных, вызывается ли она много раз.
Поэтому вы можете захотеть запустить его в цикле или для большой таблицы и использовать профилировщик для поиска загрузок. Если вы используете 11g, вам следует проверить встроенный иерархический профилировщик.
Что-то вроде этого:
begin
DBMS_HPROF.START_PROFILING (
location => 'PROF_DATA_FILE_DIR'
, filename => 'HPROF_RUN1_20111109'
);
some_pkg.generate_lots_of_work(p_id => 1234);
DBMS_HPROF.STOP_PROFILING;
end;
/
Или в цикле:
begin
DBMS_HPROF.START_PROFILING (
location => 'PROF_DATA_FILE_DIR'
, filename => 'HPROF_RUN2_20111109'
);
for i in 1..1000
loop
some_pkg.do_this(p_num => i);
end loop;
DBMS_HPROF.STOP_PROFILING;
end;
/
Очевидно, что это не поможет вам в генерации массивов данных для нагрузочного тестирования. Это всегда самая сложная часть 🙂
Ответ №2:
Все классические инструменты тестирования производительности поставщика, LoadRunner, Silk Performer, QALoad и Rational Performance Tester, имеют возможность прямого доступа к базе данных для выполнения тестов производительности по запросам напрямую или с использованием хранимых процедур.
Причина, по которой эти инструменты обладают такой возможностью, заключается в том, что они обычно существовали на рынке добрых полдесятилетия, когда стандартом для клиент = сервер была двухуровневая клиентская архитектура базы данных. Большая часть материалов, появившихся на рынке с 2000 года, в значительной степени предназначена только для Интернета.