Oracle Datareader в .Net - слишком медленно (по сети)

Прежде, чем я получу сообщение "Вы пробовали ODP.net?" отвечает, да, есть и использую сейчас.

Я перемещаю данные с оракула на сервер sql (не важно) и использую средство чтения данных в соединении оракула. Таблицы большего размера ползают. Иногда до 10 записей в секунду. Когда я заметил проблемы с производительностью, я сократил свой исходный код до простого выполнения простых вызовов Reader.Read () по всей таблице, чтобы ничто другое не замедляло его. Я пробовал клиентов MS и Oracle ODP .net. В настоящее время я использую 11g Instant Client, 64-битный на win7 64-битный, 8-гигабайтную оперативную память и все вкусности. Я использовал его в локальной сети, сейчас я использую VPN, и производительность в основном такая же. Я настроил размеры предварительной выборки безрезультатно.

Я могу запустить функцию экспорта данных в инструментах Oracle Sql DEveloper и экспортировать все данные для всей базы данных на этом же компьютере по той же сети примерно в 100 раз быстрее.

Я могу скопировать свое приложение .net на сервер Oracle и запустить на нем тот же тест производительности, и он завершится менее чем за секунду.

Итак, это не сама сеть, которая работает медленно, и не количество данных (как демонстрирует экспорт SqlDeveloper), и это не сам код .net и не oracle db (как показано при запуске его на сервере), поэтому это должна быть какая-то комбинация Datareader, используемая в любой сети.

Это моя мгновенная установка клиента? Полноценный клиент работает лучше? 64-битный клиент все испортил? Действительно в растерянности.

ОБНОВИТЬ:

С тех пор я запускал то же приложение, скомпилированное для 32-разрядной версии, и запускал на виртуальном ПК экземпляр Windows XP, на котором установлен «полный» клиент oracle (очевидно, 32-разрядная версия). Даже с уменьшенной производительностью виртуальной машины она все равно работала почти в 10 раз быстрее. Итак, определенно какая-то проблема с мгновенным клиентом, и я предполагаю, в частности, с 64-битным мгновенным клиентом. Последним тестом, подтверждающим это, будет установка 32-битного мгновенного клиента на этом же компьютере и его повторный запуск. Если найду время ...


.net oracle oracleclient odp.net datareader
person Brady Moritz    schedule 16.07.2011    source источник
comment
Это 2 дня назад, так что я подозреваю, что вы переехали. Интересно, как выглядит ваша строка подключения? Убедитесь, что вы не делаете что-то непонятное, например использование сантехники Oracle OraOLEDB в клиенте.   -  person Brett    schedule 19.07.2011
comment
В настоящее время я использую строку подключения в стиле tns, но вместо этого из моего кода ... например: SERVER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = MyHost) (PORT = MyPort)) (CONNECT_DATA = (SERVICE_NAME = MyOracleSID))); uid = myUsername; pwd = myPassword;   -  person Brady Moritz    schedule 20.07.2011
comment
Ничего очевидного. Обычно мы используем tnsnames.ora, но он должен быть таким же. Раньше я видел странную медлительность с provider = oraOlEDB ...   -  person Brett    schedule 20.07.2011
comment
Я подозреваю 64-битный Instant Client, я попробую затем на 32-битном компьютере с полной установкой, все еще в той же сети, и посмотрю, не изменится ли что-нибудь.   -  person Brady Moritz    schedule 20.07.2011

Ответы (4)


arrow_upward
0
arrow_downward

«Я могу скопировать свое приложение .net на сервер Oracle и запустить на нем тот же тест производительности, и он завершится менее чем за секунду».

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

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

Но, как вы отметили, это не может объяснить разницу во времени заманивания. Приложения могут быть недружелюбны к WAN. Обычно это сводится к тому, что для отправки и получения информации требуется слишком много оборотов, а объем информации в каждом потоке данных может быть существенно большим, чем необходимо. Возможно, что базовый механизм квитирования из вашего массового экспорта в ваше приложение полностью отличается. Один может запрашивать 100 записей за раз, в то время как другой может извлекать каждую запись последовательно (учитывая вашу разницу в скорости 100: 1). Постоянное подтверждение связи приложения с базой данных для получения одной записи за раз может существенно увеличить ваши накладные расходы и привести к падению пропускной способности.

person James Pulley    schedule 19.07.2011
comment
Проблема не в сети - я могу запустить sqldeveloper через одно и то же сетевое соединение, и это на порядок быстрее. Это верно как для VPN, так и для локальной гигабитной LAN. - person Brady Moritz; 20.07.2011
comment
И выборка 100 записей должна быть скорректирована FetchSize на считывателе, но изменения в нем не помогли (я обновлю свой вопрос, включив это, забыл добавить его изначально). Спасибо - person Brady Moritz; 20.07.2011
comment
Проводили ли вы сравнительный анализ рассматриваемого запроса с использованием собственного соединения в стиле OCI и извлечения данных по сравнению с интерфейсом ODP.NET? Это, безусловно, проблема приложения, с оставшимся вопросом о том, является ли это структурной проблемой, которая повлияет на все интерфейсы, или что-то конкретное, связанное с использованием и настройкой набора решений ODP.NET. - person James Pulley; 20.07.2011
comment
Предполагая, что SqlDeveloper использует OCI под капотом, да, это в 10+ раз быстрее. И я использовал как ODP, так и клиент .Net Oracle, оба ведут себя одинаково. Итак, оставшаяся константа - это 64-разрядная версия Oracle Instant Client. Теперь у меня есть новая виртуальная машина, на которой установлен полный клиент oracle, поэтому я попробую запустить приложение на ней и посмотрю, улучшится ли что-нибудь. - person Brady Moritz; 20.07.2011
comment
SQLDeveloper - это скрытый OCI, как и SQL + и другой стандартный набор утилит. Что нужно иметь в виду на виртуальной машине, так это то, что гипервизор будет предоставлять доступ к общему сетевому ресурсу, и любое сетевое рукопожатие будет подвергаться некоторым небольшим преувеличениям каждый раз, когда его доступ должен осуществляться через посредника. Если у вас болтливый сетевой интерфейс, это не только замедлится из-за удаленного доступа через VPN, но и из-за включения в виртуальную машину. Дельта 1: 100 кажется длинной, поэтому я все еще придерживаюсь чего-то структурного в интерфейсе .NET, чего нет в собственном OCI. - person James Pulley; 20.07.2011
comment
Хорошо, результаты тестового прогона: Пример таблицы с 15 тыс. Строк. мгновенный клиент 64 бит - 854 секунды. полноустановленный клиент 32bit - 172 секунды. 32-битный запуск внутри виртуальной машины, поэтому даже с этим недостатком он значительно быстрее. Что-то не так либо с 64bit, либо с Instant Client. Последний тест, который я смог сделать, - это загрузить 32-битный клиент экземпляра и попробовать его ... потрясающе. - person Brady Moritz; 21.07.2011
comment
Я предполагаю, что на данный момент не задан вопрос, является ли клиентское приложение 64-битным или 32-битным? Это могло иметь значение здесь. Если клиент 32-битный, а интерфейс сервера 64-битный, то в какой-то момент, когда происходит обмен данными между двумя приложениями, 32-битные слова для приложения должны быть дополнены дополнительными 32 битами, чтобы сделать 64-битные слова для 64-битных слов. битовые компоненты для понимания. Microsoft называет это «громоздким», и в первый раз это серьезно повлияло на переход архитектуры с 16-битной на 32-битную архитектуру в начале 1990-х годов. Thunking не накладывает штраф на производительность - person James Pulley; 24.07.2011
comment
Нет, я использую 64-разрядную версию Windows 7, и я компилирую приложение .net только для 64-разрядной версии. Клиент oracle на самом деле не будет работать, если вы запустите свое приложение в 32-битном режиме (.net может работать в любом из них). И насколько я знаю, сами данные с сервера должны быть идентичны между 64- и 32-битным сервером, иначе это не будет зависеть от подключения. - person Brady Moritz; 25.07.2011
comment
но ... Джеймс, я подозреваю, что Oracle делает что-то под капотом на 64-битном клиенте, что делает его медленнее, чем следовало бы. Итак, идея вашего ответа верна. - person Brady Moritz; 25.07.2011

arrow_upward
0
arrow_downward

Попробуйте увеличить размер выборки . Чем оно выше, тем меньше обходов ODP.net придется совершить для фактического получения данных, и тем выше будет производительность по сети. (Обратите внимание, что AFAIK, если у вас включен пул соединений, это делается автоматически.)

person Tridus    schedule 19.07.2011
comment
Я пробовал широкий диапазон размеров выборки, без разницы. (думал, что включил это в вопрос, извините) - person Brady Moritz; 20.07.2011

arrow_upward
0
arrow_downward

бумхауэр: вы дошли до сути? У меня похожие проблемы. Я получил небольшой импульс, поиграв с Fetchsizes. В моей тестовой среде, которая на порядки меньше, чем prod, я вижу 1,8 секунды в ODP.net и 0,2 секунды в System.Data.OracleClient. Лучшее, что я могу получить, увеличив размер выборки, - 1,6 секунды.

person lbp    schedule 10.10.2011
comment
ближе всего я пришел к выводу, что это либо. мгновенный клиент, или b. 64-битный клиент ... или, может быть, их комбинация. У меня не было времени, чтобы сузить круг вопросов. Вы используете 64-битный? - person Brady Moritz; 11.10.2011
comment
Однако я не помню большой разницы в скорости между oracleclient и odp.net ... все, что использовало 64-битный мгновенный клиент, было медленным. - person Brady Moritz; 11.10.2011
comment
Я поразил это, потому что мы начали строить на 64-битной среде, но с 32 родными dll, поэтому вынуждены были использовать x86. А затем заметил, что System.Data.OracleClient устарел, поэтому был перемещен в «мгновенные» 32-разрядные драйверы ODP.net. Я думаю, что 32/64 бит здесь может быть отвлекающим маневром, я подозреваю, что есть некоторые настройки, связанные с сетью, которые не установлены с помощью мгновенного клиента - хотя я еще не пробовал «установленный» ODP.net. - person lbp; 11.10.2011
comment
Я действительно подозреваю, что мгновенный клиент больше, чем аспект x64. - person Brady Moritz; 11.10.2011

arrow_upward
0
arrow_downward

У меня аналогичная проблема, но она временная. У меня есть запрос Oracle, который обычно выполняется около 1 секунды, но иногда около обеда требуется 30 секунд для запуска с использованием .Net. Если в это время я запускаю его с помощью Oracle SQL Developer на том же компьютере, это все равно занимает 1 секунду.

Эта проблема длится всего около 10 минут в день. Кроме того, у моего коллеги точно такая же проблема возникает в одно и то же время, и в то же время она исчезает.

Кажется, что это может быть комбинация сети и драйвера .Net Oracle, но я не знаю, как его найти. Также другие запросы SQL в настоящее время не выполняются медленно, а только один конкретный запрос, который возвращает только 1200 строк.

РЕДАКТИРОВАТЬ: я узнал, что другой коллега делал копию большого файла по сети во время замедления. Чтобы доказать это, я заставил его сделать это снова, и произошло то же самое, но запрос все еще был быстрым в Oracle SQL Developer. Так что это комбинация сети и драйвера .Net Oracle. Я использую 64-битную версию BTW.

person user2882190    schedule 19.06.2014