.net - 为什么我的 iSeries/ASP.NET MVC 4 应用程序中没有重用连接？

Question

我们正在 Windows 2008 服务器场上运行 MVC 4 Web 应用程序。我们一直在尝试将我们的服务器群升级到 Windows 2008 R2 64 位服务器，但在 iSeries(运行 V7R1)上遇到了连接池问题。我们经常调用 DB2 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 开始，iSeries 上的连接数(QZDASOINIT 作业)稳步增加，损害了 iSeries 和我们应用程序的性能。代码库是 正好与 2008 年 32 位服务器上的相同。我们为 Any CPU 设置了目标平台，并且在 IIS 中将“启用 32 位应用程序”设置为 True。我们在本月早些时候尝试升级到这些服务器，重置 IIS 并没有像预期的那样自动终止机器上的连接，并且在我们完全恢复到旧服务器之前不会创建任何新的连接。

几乎似乎它没有选择已经建立的连接并不断创建新的连接。有谁知道当涉及到与 iSeries 的连接池时，在升级到 32 位到 64 位时我们是否遗漏了一个步骤？

Answer 1

问题回顾 :将 ASP.NET MVC 4 Web 应用程序从 32 位 Windows 2008 服务器群移动到 Windows 2008 R2 64 位服务器时，数量 QZDASOINIT IBM i 上创造的工作岗位从大约 2,000 个跃升至大约 200,000 个。代码库没有改变，唯一改变的是执行环境。

一些需要了解的相关信息 QZDASOINIT作业... 默认情况下，这些作业是在子系统中创建的 QUSRWRK (尽管它们也可能出现在 QSYSWRK 和 QSERVER 中，如果 QUSRWRK 子系统在请求 ODBC 连接时未处于事件状态)。 QUSRWRK配置为创建其中之一 QZDASOINIT子系统启动后立即执行作业。如果发出 ODBC 请求并且没有 QZDASOINIT有职位空缺，还有 2 个 QZDASOINIT工作将开始。每个QZDASOINIT作业将在结束前处理 200 个 ODBC 请求。可以使用 CHGPJE 更改所有这些默认值以及更多默认值。或 CHGSBSD命令。
QZDASOINIT工作有一个或两个“类”。这些作业的执行可以使用这些类进行微调。

您可以找到有关您当前活跃的信息 QZDASOINIT使用 DSPACTPJ 的工作命令。

资源:

CHGPJE – Change Prestart Job Entry

CHGSBSD – Change Subsystem Description

CRTCLS – Create Class

DSPACTPJ – Display Active Prestart Jobs

ENDHOSTSVR – End Host Server

ENDSBS – End Subsystem

WRKCLS – Work with Classes

Performance considerations with QZDASOINIT jobs

可能的“解决方案”#1:

在 Windows 端的连接字符串中，更改 MaximumPoolSize=-1至 MaximumPoolSize=XXX其中 XXX 是一些数字，它允许您的 ASP.NET 应用程序运行得相当好，但不会降低 IBM i 上的性能。我建议使用 2,000，因为当应用程序在 32 位服务器上运行时，这似乎是可以容忍的。

可能的“解决方案”#2:

让 IBM i 管理员对 IBM i 进行一些更改——因为您知道服务器群的 IP 地址范围，管理员可以设置一个新的子系统，该子系统除了为您的应用程序 ODBC 连接提供服务之外什么都不做。
更改允许的最大数量 QZDASOINIT使用 CHGPJE 的工作命令——同样，我建议从 2,000 开始并根据需要调整它以满足应用程序的性能和对 IBM i 的影响。如有必要，管理员可以设置一个将杀死所有 QZDASOINIT 的作业。新子系统中的作业 - 通过结束该子系统 (ENDSBS) 或 ENDHOSTSVR SERVER(*DATABASE) ENDACTCNN(*DATABASE) (我会结束子系统，但您的管理员会知道什么最适合您的环境)。

其他一些本身不是解决方案但可能会有所帮助的建议:

限制 ASP.NET 应用程序中并发执行的线程数。显然，这不是一件快速或容易的事情，而是要为应用程序的下一次迭代添加注释。

更改 MaximumUseCount=100匹配您使用的任何使用计数与 QZDASOINIT工作。

我在“解决方案”周围加上引号是因为虽然它们可能允许您将应用程序移至新环境，但它们实际上并不能解决问题。