来自.Net iSeries Provider的AS 400性能

时间:2010-06-17 18:11:18

标签: asp.net performance ibm-midrange

首先,我不是AS 400的人。所以请原谅我在这里问任何无用的问题。

基本上,我正在开发一个需要访问AS400以获取实时数据的.Net应用程序。虽然我有系统工作,但我在查询之间得到了非常不同的性能结果。通常,当我在AS400上针对SPROC发出第一个请求时,我看到了大约14秒的时间来获取完整的数据集。在初始呼叫之后,任何后续呼叫通常只需要约1秒钟才能返回。在再次花费14秒之前,这种性能提升大约需要20分钟左右。

有趣的是,如果存储过程直接在iSeries Navigator上执行,它总是在几毫秒内返回(响应时间没有变化)。

我想知道它是否是缓存/执行计划问题,但我只能将我的SQL SERVER逻辑应用于AS400,而AS400并不总是匹配。

当我使用iSeries数据提供程序用于.Net时,有什么建议可以做些什么来接收更一致的响应时间或只是洞察AS400为什么会以这种方式行事?我应该使用更好的访问方法吗?

以防万一,这是我用来连接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 个答案:

答案 0 :(得分:2)

我发现红皮书Integrating DB2 Universal Database for iSeries with Microsoft ADO .NET对于诊断这些问题非常有用。

专门查看客户端和服务器端跟踪以帮助隔离问题。并且不要害怕致电IBM软件支持。他们可以帮助您设置分析以找出问题。

答案 1 :(得分:2)

您可能希望尝试使用其他驱动程序连接到AS400-DB2系统。我使用了2个选项。

  1. 标准的jt400.jar驱动程序,用于创建一个简单的java Web服务来获取我的数据
  2. 该公司的司机名为HIT软件(www.hitsw.com)
  3. 显然,第一个选择是两者中较慢的选择,但那是免费的做事方式。

答案 2 :(得分:2)

与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”来禁用它。如果连接池是第二次尝试速度快得多的原因,则禁用连接池应该使每个请求的执行速度与第一次一样慢。

答案 3 :(得分:1)

我已经看到了几年来iSeries SQL(ODBC)查询的类似性能。我认为这是野兽本质的一部分 - 当OS / 400被访问时,它会动态地将数据从磁盘移动到内存。

FWIW,我也注意到iSeries更像是一辆拖拉机而不是一辆赛车。它可以更好地处理大负荷。在一个案例中,我将大约十几个简短的查询合并为一个可疑的查询,并将执行时间从20秒减少到大约2秒。

答案 4 :(得分:1)

我过去不得不从AS / 400中提取数据,基本上有几件事对我有用:

1)每晚将数据转储到SQL Server表中我可以控制索引,本机SqlClient每次都击败IBM DB2 .NET客户端
2)与您的AS400程序员交谈并确保您使用的命令正在命中逻辑文件而不是物理(他们世界中的逻辑v / s物理类似于我们的表v /的意见)
3)使用SQL Server上的链接服务器创建视图并查询您的视图。

答案 5 :(得分:1)

当从Websphere Application Server(WAS)上托管的Java解决方案以及IIS上托管的.Net解决方案连接到Iseries数据时,我观察到了相同的行为。当天的第一个电话总是比第二个更“昂贵”。 第一次调用的延迟是由Iseries设置作业以服务请求的“设置”时间引起的(作业名称是子系统QUSRWRK中的QZDASOINIT)。后续调用将重用保持活动状态等待更多传入请求的现有作业。 QZDASOINIT作业的数量以及它们保持活动的时间可在Iseries上配置。 有关如何调整预启动作业条目的文档: http://www.ibmsystemsmag.com/ibmi/tipstechniques/systemsmanagement/Tuning-Prestart-Job-Entries/ 我想这是一个合理的假设,在WAS和IIS上“当天的第一次通话”也有一些开销。

答案 6 :(得分:0)

尝试创建存储过程。这将使用存储过程创建和缓存您的访问计划,因此优化器不必查看SQL缓存或重新优化。