Почему не используются соединения в моем приложении iSeries/ASP.NET MVC 4?

Мы запускаем веб-приложение MVC 4 на ферме серверов Windows 2008. Мы пытаемся обновить серверную ферму до 64-разрядных серверов Windows 2008 R2, но столкнулись с проблемой объединения пулов в iSeries (работает с V7R1). Мы часто вызываем хранимые процедуры Java java и включаем объединение пулов, чтобы сократить время, необходимое для установления соединений. Ниже приведен пример строки подключения.

<add name="DB2" connectionString="ConnectionTimeout=45;Pooling=true;MinimumPoolSize=1;MaximumPoolSize=-1;MaximumUseCount=100;CheckConnectionOnOpen=true;DataSource=XXX;Naming=SQL;DataCompression=True;UserID=username;password=pwd;DefaultCollection=XXX" />

Начиная с перехода на 2008R2 количество подключений (заданий QZDASOINIT) увеличивается на iSeries, постоянно снижая производительность iSeries и, таким образом, в нашем приложении. База кода точно такая же, как и на 32-разрядных серверах 2008 года. У нас есть целевая платформа, установленная для любого процессора, и для "Инициализация 32-разрядных приложений" установлено значение "Истина" в IIS. Мы попытались перейти на эти серверы ранее в этом месяце, и сброс IIS не смог автоматически убить соединения в этом поле, как предполагалось, и не будет создавать никаких новых, пока мы полностью не вернемся к нашим старым серверам.

Похоже, что он не собирает подключений, которые были созданы, и постоянно создает новые. Кто-нибудь знает, есть ли какой-то шаг, который мы пропустили при обновлении до 32-бит до 64-битного, когда дело доходит до пула соединений с iSeries?

Ответ 1

Резюме проблемы: при перемещении веб-приложения ASP.NET MVC 4 из 32-разрядной серверной фермы Windows 2008 на 64-разрядные серверы Windows 2008 R2 количество созданных QZDASOINIT заданий на нашей IBM я скачки от 2000 до 200 000. База кода не изменяется, единственное, что изменилось, это среда выполнения.

Некоторые важные вещи, которые нужно знать о заданиях QZDASOINIT... По умолчанию эти задания создаются в подсистеме QUSRWRK (хотя они также могут встречаться в QSYSWRK и QSERVER, если подсистема QUSRWRK не активен при запросе соединения ODBC). QUSRWRK настроен на создание одного из этих QZDASOINIT заданий сразу же после запуска подсистемы. Если выполняется запрос ODBC и нет заданий QZDASOINIT, еще 2 задания QZDASOINIT будут запущены. Каждое задание QZDASOINIT будет обрабатывать 200 запросов ODBC до окончания. Все эти значения по умолчанию и многое другое можно изменить с помощью команд CHGPJE или CHGSBSD.

Рабочие задания

QZDASOINIT имеют один или два класса. Выполнение этих заданий может быть настроено с помощью этих классов.

Вы можете узнать информацию о ваших активных действиях QZDASOINIT с помощью команды DSPACTPJ.

Ресурсы

CHGPJE - Изменить запись задания Prestart

CHGSBSD - Изменить описание подсистемы

CRTCLS - Создать класс

DSPACTPJ - Показать активные задания Prestart

ENDHOSTSVR - Конечный хост-сервер

ENDSBS - Конечная подсистема

WRKCLS - Работа с классами

Возможное "решение" # 1:

В строке подключения на стороне Windows измените MaximumPoolSize=-1 на MaximumPoolSize=XXX, где XXX - это некоторое число, которое позволяет вашему приложению ASP.NET функционировать достаточно хорошо, но не ухудшает производительность на IBM i. Я бы предложил использовать 2000, поскольку это казалось приемлемым, когда приложение выполнялось на 32-разрядных серверах.

Возможное "решение" # 2:

Попросите администратора IBM я внести некоторые изменения в IBM я - поскольку вы знаете диапазон IP-адресов фермы серверов, администратор может настроить новую подсистему, которая ничего не будет делать, кроме как обслуживать соединения ODBC приложений. Измените максимальное количество разрешенных QZDASOINIT заданий с помощью команды CHGPJE - снова, я бы предложил начать с 2000 и настроить его по мере необходимости, чтобы удовлетворить вашу производительность приложения и влияние на IBM i. Если необходимо, администратор может настроить задание, которое убьет все задания QZDASOINIT в новой подсистеме - либо закончив эту подсистему (ENDSBS), либо ENDHOSTSVR SERVER(*DATABASE) ENDACTCNN(*DATABASE) (я бы закончил подсистему, но ваш администратор узнает, что будет работать лучше всего в вашей среде).

Некоторые другие предложения, которые не являются самими решениями, но могут быть полезными:

Ограничение количества одновременных выполнения потоков в приложении ASP.NET. Очевидно, что это не простое или легкое дело, а что-то, что нужно добавить в примечания для следующей итерации приложения.

Изменение MaximumUseCount=100 для соответствия любому счету использования, который вы используете с заданиями QZDASOINIT.

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

Ответ 2

Я видел проблемы до того момента, когда приложение, использующее пулы подключений, отлично работает как stand-a-lone, но при запуске на сервере приложений вы получаете как приложение, так и сервер приложений, делающий пул соединений. Проблема в том, что сервер приложений никогда не выпускает соединение.

Я недостаточно разбираюсь в ASP.NET или IIS, чтобы сказать вам, где искать, но, возможно, этого достаточно.

Если нет, это поможет узнать

какую версию IBM iAccess вы загрузили, а скорее 32 или 64 бит и какой уровень пакета обновления вы используете.
используемый драйвер. Я бы предположил, что драйвер .NET, но я знаю, что MS предоставляет функциональность для использования ODBC или OLEDB-драйверов с .NET.

Чарльз

Ответ 3

Отключение пула соединений может решить вашу проблему. В строке подключения: Pooling=false;