Производительность AS 400 от провайдера .Net iSeries - PullRequest
6 голосов
/ 17 июня 2010

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

По сути, я работаю над приложением .Net, которому требуется доступ к AS400 для получения некоторых данных в реальном времени.Несмотря на то, что система работает, я получаю очень разные результаты производительности между запросами.Как правило, когда я делаю первый запрос к SPROC на AS400, я вижу ~ 14 секунд, чтобы получить полный набор данных.После этого первоначального вызова любые последующие вызовы обычно возвращаются через ~ 1 секунду.Это улучшение производительности сохраняется в течение ~ 20 минут или около того, прежде чем оно снова займет 14 секунд.

Интересно то, что если хранимая процедура выполняется непосредственно в Навигаторе iSeries, она всегда возвращается в течение миллисекунд (нетизменить время отклика).

Интересно, это проблема с планом кэширования / выполнения, но я могу только применить свою логику SQL SERVER к AS400, что не всегда совпадает.чтобы получить более стабильное время отклика или просто понять, почему AS400 работает таким образом, когда я использовал поставщик данных iSeries для .Net?Есть ли лучший способ доступа, который я должен использовать?

На всякий случай, вот код, который я использую для подключения к AS400

     Dim Conn As New IBM.Data.DB2.iSeries.iDB2Connection(ConnectionString)
  Dim Cmd As New IBM.Data.DB2.iSeries.iDB2Command("SPROC_NAME_HERE", Conn)
  Cmd.CommandType = CommandType.StoredProcedure

  Using Conn
   Conn.Open()

   Dim Reader = Cmd.ExecuteReader()
   Using Reader
    While Reader.Read()

               'Do Something

    End While
    Reader.Close()
   End Using

   Conn.Close()
  End Using

РЕДАКТИРОВАТЬ: немного посмотрев на этоПри использовании некоторых комментариев ниже я начинаю задаваться вопросом, испытываю ли я это из-за преимуществ пула подключений?Мысли?

Ответы [ 7 ]

2 голосов
/ 08 декабря 2012

Каждое соединение с iSeries поддерживается заданием. При первом соединении драйвер iSeries должен создать пул соединений, запустить задание и связать это задание с объектом соединения. Когда вы закрываете соединение, драйвер возвращает этот объект в пул соединений, но не завершает работу на сервере.

Вы можете включить трассировку, чтобы определить, что происходит при первой попытке подключения. Для этого добавьте «Trace = StartDebug» в строку подключения и включите ведение журнала трассировки в окне, где выполняется ваш код. Это можно сделать с помощью инструмента «cwbmptrc» в программном каталоге клиентского доступа:

c: \ Program Files (x86) \ IBM \ Client Access> cwbmptrc.exe + a

Ведение журнала ошибок включено
Трассировка включена

Имя файла журнала ошибок: C: \ Users \ Public \ Documents \ IBM \ Client Access \ iDB2Log.txt

Имя файла трассировки: C: \ Users \ Public \ Documents \ IBM \ Client Access \ iDB2Trace.txt

Вывод трассировки даст вам представление о том, какие операции выполняет драйвер, и сколько времени требуется для выполнения каждой операции. Только не забудьте отключить трассировку, когда закончите (cwbmptrc.exe -a)

Если вы не хотите связываться с трассировкой, быстрый тест, чтобы определить, не является ли пул соединений задержкой, должен отключить его, добавив «Pooling = false» в строку подключения. Если пул соединений является причиной, по которой ваша вторая попытка выполняется намного быстрее, отключение пула соединений должно заставить каждый запрос выполняться так же медленно, как и первый.

2 голосов
/ 05 июля 2010

Возможно, вы захотите попробовать другой драйвер для подключения к системе AS400-DB2. Я использовал 2 варианта.

  1. стандартный драйвер jt400.jar для создания простого веб-сервиса java для получения моих данных
  2. драйверы от компании под названием HIT software (www.hitsw.com)

Очевидно, что первый вариант будет медленнее двух, но это свободный способ делать вещи.

2 голосов
/ 17 июня 2010

Я нашел Redbook Интеграция DB2 Universal Database для iSeries с Microsoft ADO .NET , которая полезна для диагностики подобных проблем.

Специально изучите трассировки на стороне клиента и сервера, чтобы помочь локализовать проблему. И не бойтесь обращаться в службу поддержки программного обеспечения IBM. Они могут помочь вам настроить профилирование, чтобы выяснить проблему.

1 голос
/ 15 сентября 2013

Я наблюдал такое же поведение при подключении к данным Iseries из решений Java, размещенных на Websphere Application Server (WAS), а также решений .Net, размещенных на IIS. Первый звонок дня всегда «дороже», чем второй. Задержка при первом вызове вызвана временем «установки» для Iseries, чтобы настроить задание для обслуживания запроса (имя задания QZDASOINIT в подсистеме QUSRWRK). Последующие вызовы будут повторно использовать существующие задания, которые остаются активными, ожидая большего количества входящих запросов. Количество заданий QZDASOINIT и продолжительность их активности можно настроить в Iseries. Один документ о том, как настроить ваши предварительные записи работы: http://www.ibmsystemsmag.com/ibmi/tipstechniques/systemsmanagement/Tuning-Prestart-Job-Entries/ Я полагаю, что было бы разумным допущение, что на WAS и IIS накладываются некоторые накладные расходы на "первый вызов дня".

1 голос
/ 17 июня 2010

Раньше мне приходилось извлекать данные из AS / 400, в основном для меня работало несколько вещей:

1) Ночной сброс данных в таблицу SQL Server, где я мог контролироватьиндексы, собственный SqlClient каждый раз побеждает клиента IBM DB2 .NET2) Поговорите с одним из ваших программистов AS400 и убедитесь, что используемая вами команда работает с логическим файлом, а не с физическим (логическое v / s физическое в их мире сродни нашим таблицам v / s).Просмотры)3) Создание представлений с использованием связанного сервера на сервере SQL и запрос ваших представлений.

1 голос
/ 17 июня 2010

Я видел аналогичную производительность запросов iSeries SQL (ODBC) в течение нескольких лет. Я думаю, что это часть природы зверя - OS / 400 динамически перемещает данные с диска в память при обращении к ним.

FWIW, я также заметил, что iSeries больше похож на трактор, чем на гоночную машину. Гораздо лучше справляется с большими нагрузками. В одном случае я объединил около дюжины коротких запросов в один чудовищный и сократил время выполнения с примерно 20 секунд до примерно 2 секунд.

0 голосов
/ 29 июня 2010

Попробуйте создать хранимую процедуру.Это создаст и кеширует ваш план доступа с помощью хранимой процедуры, поэтому оптимизатору не нужно искать в кеше SQL или повторно оптимизировать.

...