为什么在我的iSeries / ASP.NET MVC 4应用程序中不重用连接？ [英] Why aren't connections being reused in my iSeries/ASP.NET MVC 4 app?
问题描述
我们正在Windows 2008服务器场上运行MVC 4 Web应用程序。我们一直在尝试将服务器场升级到Windows 2008 R2 64位服务器，但是在iSeries（运行V7R1）上的连接池遇到了问题。我们经常调用DB2 Java存储过程，并启用了连接池以减少建立连接所需的时间。下面是我们正在使用的连接字符串的示例。
We are running an MVC 4 web application on a Windows 2008 server farm. We have been trying to upgrade our server farm to Windows 2008 R2 64-bit servers but have run into an issue with connection pooling on an iSeries (running V7R1). We frequently call DB2 java stored procedures and have enabled connection pooling to reduce the time it takes to establish connections. Below is an example of the connection string we’re using.
< 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位服务器上的相同。我们为任何CPU设置了目标平台，并且在IIS中将启用32位应用程序设置为True。我们试图在本月初升级到这些服务器，并且重新设置IIS并没有像预期的那样自动终止机箱上的连接，并且在我们完全恢复为旧服务器之前不会创建任何新的连接。
Since going to 2008R2, the number of connections (QZDASOINIT jobs) increases on the iSeries steadily, hurting performance on the iSeries and thus in our application. The code base is exactly the same as it was on the 2008 32-bit servers. We have the target platform set for Any CPU and have "Enable 32-bit Applications" set to True in IIS. We tried to upgrade to these servers earlier in the month and resetting IIS didn’t automatically kill the connections on the box like it’s supposed to and would not create any new ones until we completely reverted to our older servers.
几乎似乎不是在捡起已经建立的连接并不断创建新的连接。没有人知道在与iSeries进行连接池升级到32位到64位时是否错过了我们的步骤？
It almost seems like it is not picking up connections that have been made and continuously creates new ones. Does anyone know if there is a step we missed when upgrading to 32-bit to 64-bit when it comes to connection pooling with an iSeries?
推荐答案
问题摘要：将ASP.NET MVC 4 Web应用程序从32位Windows 2008服务器场迁移到Windows 2008 R2 64位服务器时，<$ c在我们的IBM i上创建的$ c> QZDASOINIT 职位从大约2,000个跃升至大约200,000个。代码库保持不变，唯一改变的是执行环境。
Recap of the problem: when moving an ASP.NET MVC 4 web application from a 32-bit Windows 2008 server farm to Windows 2008 R2 64-bit servers the number of QZDASOINIT jobs created on our IBM i jumps from around 2,000 to around 200,000. The code base is unchanged, the only thing that has changed is the execution environment.
关于 QZDASOINIT 作业...默认情况下，这些作业在子系统 QUSRWRK 中创建（尽管它们也可以在 QSYSWRK 和 QSERVER （如果请求ODBC连接时 QUSRWRK 子系统未激活）。 QUSRWRK 配置为在子系统启动后立即创建这些 QZDASOINIT 作业之一。如果发出ODBC请求并且没有 QZDASOINIT 作业可用，则会启动另外2个 QZDASOINIT 作业。每个 QZDASOINIT 作业在结束之前将处理200个ODBC请求。所有这些默认值和更多默认值都可以使用 CHGPJE 或 CHGSBSD 命令进行更改。
Some relevant things to know about QZDASOINIT jobs... By default these jobs are created in the subsystem QUSRWRK (though they can also crop up in QSYSWRK and QSERVER if the QUSRWRK subsystem is not active when an ODBC connection is requested). QUSRWRK is configured to create one of these QZDASOINIT jobs as soon as the subsystem is started. If an ODBC request is made and no QZDASOINIT jobs are available, 2 more QZDASOINIT jobs will be started. Each QZDASOINIT job will process 200 ODBC requests before ending. All of these defaults and more can be changed using the CHGPJE or CHGSBSD commands.
QZDASOINIT 作业有一个或两个类。可以使用这些类来微调这些作业的执行。
QZDASOINIT jobs have one or two "classes". Execution of these jobs can be fine-tuned using these classes.
您可以找到有关当前活动的 QZDASOINIT DSPACTPJ 命令执行作业。
You can find out information about your currently active QZDASOINIT jobs by using the DSPACTPJ command.
资源：
可能的解决方案＃1：
在Windows端的连接字符串中，将 MaximumPoolSize = -1 更改为 MaximumPoolSize = XXX 其中XXX是一个数字，它可以使您的ASP.NET应用程序正常运行，但不会降低IBM i的性能。我建议使用2,000，因为当应用程序在32位服务器上运行时，这似乎可以容忍。
In your connection string on the Windows side, change MaximumPoolSize=-1 to MaximumPoolSize=XXX where XXX is some number that allows your ASP.NET application to function reasonably well but doesn't degrade performance on the IBM i. I would suggest using 2,000 since that seemed to be tolerable when the application was running on 32-bit servers.
可能的解决方案＃2：
让IBM i管理员对IBM i进行一些更改–由于您知道服务器场的IP地址范围，因此管理员可以设置一个新的子系统，该子系统将除了为您的应用程序提供ODBC连接外，什么都不做。
使用 CHGPJE 命令更改允许的 QZDASOINIT 作业的最大数量–同样，我建议从2,000并根据需要进行调整，以满足您的应用程序的性能和对IBM i的影响。如有必要，管理员可以设置作业以终止新子系统中的所有 QZDASOINIT 作业–通过终止该子系统（ENDSBS）或 ENDHOSTSVR SERVER（* DATABASE）ENDACTCNN（* DATABASE）（我将结束子系统，但您的管理员将知道什么在您的环境中最有效）。
Have an IBM i administrator make some changes on the IBM i – since you know the IP address range of your server farm the administrator can set up a new subsystem that will do nothing but service your applications ODBC connections.
Change the maximum number of allowed QZDASOINIT jobs using the CHGPJE command – again, I would suggest starting at 2,000 and adjusting it as needed to satisfy your application's performance and impact on the IBM i. If necessary, the administrator could set up a job that will kill all QZDASOINIT jobs in the new subsystem – either by ending that subsystem (ENDSBS) or ENDHOSTSVR SERVER(*DATABASE) ENDACTCNN(*DATABASE) (I would end the subsystem but your administrator will know what will work best in your environment).
某些本身不是解决方案但可能会有所帮助的建议：
Some other suggestions that aren't solutions themselves but may be helpful:
限制ASP.NET应用程序中并发执行线程的数量。显然，这不是一件快速或容易的事情，而是要在应用程序的下一次迭代中添加一些注意事项。
Limiting the number of concurrently executing threads in your ASP.NET application. Obviously not a quick or easy thing to do but something to put in the notes for the next iteration of the application.
更改 MaximumUseCount = 100 来匹配您在 QZDASOINIT 作业中使用的使用次数。
Changing the MaximumUseCount=100 to match whatever use count you're using with the QZDASOINIT jobs.
I在解决方案周围加上引号，因为尽管它们可能使您可以将应用程序移至新环境，但实际上并不能解决问题。
I put quotes around "solutions" because while they might allow you to get your application moved to the new environment they don't actually fix the problem.
这篇关于为什么在我的iSeries / ASP.NET MVC 4应用程序中不重用连接？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
