Повлияет ли производительность, когда процедура базы данных вызывается из приложения много раз?

Question

Повлияет ли производительность, когда процедура базы данных вызывается из приложения много раз?

В моем проекте мы вызываем процедуру оракула из нашего приложения c ++ с
помощь библиотеки Pro * C / C ++, предоставленной оракулом.

У нас есть одна большая процедура, и моя идея состоит в том, чтобы разделить процедуру на две для модульности. Но их совет состоит в том, чтобы вызвать процедуру на один раз, и выполнить все работы в кадре.

Причина, по которой я их получил, заключается в том, что это приведет к снижению производительности, поскольку прикладная программа многократно взаимодействует с базой данных.

Я согласен, вышеописанный сценарий будет происходить, когда приложение подключается к базе данных, вызывает процедуру и, наконец, отключает базу данных для каждого вызова процедуры. Но на самом деле мы создаем пул соединений при запуске и повторно используем эти предварительно подключенные соединения базы данных для взаимодействия с базой данных.

Информация о моей заявке:

это multi-threaded application, который обрабатывает около 1000 запросов в секунду с размером пула потоков 20. В настоящее время для каждого запроса мы взаимодействуем с базой данных 4 раза.

РЕДАКТИРОВАТЬ:

«Переключение между PLSQL и SQL происходит намного быстрее, чем наоборот».
Q1. Как это связано с моим актуальным вопросом? Мой вопрос о том, чтобы разделить процедуру на две равные части. Предположим, у меня есть 4 запроса, выполненных в процедуре, я просто разделил их на два, как процедуру a и процедуру b, и каждая процедура будет иметь два запроса.

msgstr «вызовы pro * c, вызывающие PLSQL, — это снижение производительности».
Q2. Вы имеете в виду связь между приложением (pro * C / C ++) и базой данных (оракул) здесь? Если это так, было ли общение большим успехом?

В прикрепленной ссылке «спросить Тома»: «Но не бойтесь вообще вызывать SQL из PLSQL — это то, что PLSQL делает лучше всего» Q4. Будет ли происходить переключение контекста, пока мы вызываем SQL из PLSQL? Потому что, как указано выше, это не оказывает никакого влияния на производительность.

1

c++multithreading oracle oracle-pro-c performance

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Ваш совет верен, было бы лучше выполнить все задачи базы данных одновременно. В вашем сценарии есть два основных влияния на производительность

Переключение контекста pro * c между механизмом SQL и механизмом PL / SQL для многократного запуска потоков. Обычно самая большая проблема во многих вызовах PL / SQL из клиентского приложения.
Затраты сетевого стека (TNS) при обмене данными между вашим приложением pro * c и механизмом базы данных, особенно если ваше приложение находится на другом физическом хосте.

Сказав это, вы создаете пул соединений в конце приложения, слушатель TNS должен также иметь пул завещанных теневых процессов сервера, ожидающих каждого сетевого соединения (это настраивается на listener.ora).

Вход / выход из OCI, когда теневой процесс уже ожидает соединения, очень быстрый и не имеет большого значения для задержки — я не буду беспокоиться об этом, если не будет запущен новый теневой процесс на сервере — тогда это может быть очень дорогой звонок. Поскольку вы используете пул соединений на стороне клиента, это обычно не проблема, а просто что-то, что нужно учитывать из-за многопоточности ваших вызовов. Как только вы исчерпали пул теневых процессов сервера, вы заметите значительное ухудшение, если прослушиватель TNS должен запустить больше теневого процесса сервера.

Отредактируйте в ответ на новые вопросы:

Это очень связано. Как указывалось ранее, вы должны минимизировать количество вызовов plsql и sql в вашем приложении C ++. Каждый вызов PLSQL в вашем вызове приложения C ++ вызывает механизм SQL, который затем вызывает механизм PLSQL для вызова процедуры. Поэтому, если вы разделите вашу процедуру на 2 — вы удвоите переключение контекста SQL на PLSQL, что является более дорогим переключением, как описано в статье Тома Кайта и из моего личного опыта.
Ответ на вопрос 1. Но, как я уже говорил ранее, издержки на связь вторые, если только ваши хосты не находятся в разных физических сетях и типах передаваемых вами данных. Например, большие параметры объекта C ++ и большие результирующие наборы Oracle со многими вызовами, очевидно, будут влиять на задержку связи с циклом передачи. Помните, что с большим количеством вызовов PLSQL вы также добавляете больше трафика SQLNET для настройки каждого соединения и набора результатов.
нет 3. вопроса
PLSQL к SQL в движке PLSQL ничтожно мал, поэтому не зацикливайтесь на этом. Поместите все ваши вызовы SQL в 1 вызов PLSQL для максимальной производительности. Не разделяйте звонки, просто чтобы быть более красноречивыми при высокой производительности.

1