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

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

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

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

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

Информация о моем приложении:

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

ИЗМЕНИТЬ:

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

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

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


c++ multithreading performance oracle oracle-pro-c
person VINOTH ENERGETIC    schedule 13.01.2016    source источник
comment
Вы измерили его, чтобы увидеть, каково влияние на реальный мир?   -  person Burhan Ali    schedule 22.01.2016

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

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

Изменить в ответ на новые вопросы:

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

  2. Ответ в 1. Но, как я уже говорил ранее, накладные расходы на связь являются вторыми, если только ваши хосты не находятся в разных физических сетях и типах данных, которые вы передаете. Например, большие параметры объекта C++ и большие наборы результатов Oracle с большим количеством вызовов, очевидно, повлияют на задержку связи при круговых поездках. Помните, что с увеличением количества вызовов PLSQL вы также добавляете больше трафика SQLNET для настройки каждого соединения и набора результатов.

  3. нет 3. вопрос

  4. PLSQL to SQL в движке PLSQL незначителен, так что не зацикливайтесь на этом. Поместите все вызовы SQL в один вызов PLSQL для максимальной пропускной способности. Не разделяйте звонки только для того, чтобы быть более красноречивым в ущерб производительности.

person Rob Mascaro    schedule 14.01.2016
comment
я понял, что движок plsql отличается, а движок sql - другой. так как два движка разные, для переключения контекста потребуется время. Учтите, что я разделяю свою процедуру на две равные части. Согласно моему пониманию, переключение контекста будет происходить для каждого запроса sql в процедуре. Таким образом, даже если мы разделим процедуру, переключение контекста будет происходить одинаковое количество раз. Правильно ли я понимаю? - person VINOTH ENERGETIC; 08.02.2016
comment
Вы почти правы - переключение между PLSQL и SQL происходит намного быстрее, чем наоборот. Таким образом, имея несколько вызовов SQL в ваших 1 или 2 вызовах PLSQL, я бы не слишком беспокоился. Однако наличие большого количества вызовов pro*c, которые вызывают SQL, затем подпрограмму PLSQL и т. д., что я видел много раз, является большим ударом по производительности. Дополнительная информация здесь: asktom.oracle .com/pls/apex/ - person Rob Mascaro; 08.02.2016
comment
Пожалуйста, смотрите новое редактирование. Я считаю, что в статье «Спросите Тома» это должно ответить на ваш вопрос, и было бы признательно, если бы вы отметили это так. - person Rob Mascaro; 12.02.2016
comment
@ Роб Маскаро Большое вам спасибо за ваше терпение.. Теперь я понял. Я думал, что приложение C++ будет напрямую вызывать движок PL/SQL. Теперь я понял, что он будет вызывать механизм SQL, который, в свою очередь, вызывает механизм PL/SQL. Но мне любопытно теперь, почему это называется так? Опубликовал еще один вопрос, связанный с этим. ="почему движок sql вызывается для вызова pl sql из клиентского приложения"> stackoverflow.com/questions/35402262/ - person VINOTH ENERGETIC; 15.02.2016