DB2 用户交流：性能缺陷

在因特网上，竞争的胜负常常在于 “一瞬” 之差。返回信息时的延迟就意味着丢失业务。因此，在开始设计应用程序时，就要考虑到性能问题。

在检查客户的应用程序和基础结构时，我发现的最常见的问题是为分布式 Java 应用程序提供服务的连接、内存或计算能力的效率很低。在面向服务环境中，进程分布在许多本地和远程服务器上。对一位客户的 Java 应用程序的分析表明，这个应用程序必须连接七个不同的服务器才能完成关键的事务。其中一些服务器已经达到 100% 利用率，所以这个应用程序不得不等待连接。因此，应用程序常常产生不可预测的事务结果。当然，通常认为这是数据库惹的祸；但是，在这种情况下，糟糕的性能不是数据库导致的，而是另有出因。

当我查看分布式服务器的统计数据、监视报告和错误日志时，却发现为了节省资源，监视功能已经被关闭了。打开监视之后，又难以通过服务器-服务器路由跟踪事务 “服务” 和协调日志上不同的时区时间戳。

在某些服务中，没有进行 SQL 错误码检查。所以，无论数据库 SQL 是否成功，服务都不报告错误。因为服务不处理来自 SQL 的错误，数据库也没有在表结构中定义引用完整性关系，所以这个事务和数据库完整性问题导致了错误的数据。

一种有问题的 Java 应用程序编程方法是把整个 SQL 结果集都放到内存或持久化层中，这个问题在对象关系映射、Hibernate 或 iBathis 应用程序体系结构中很常见，应该在应用程序测试阶段加以纠正。这种做法在测试环境中常常效果良好，因为在测试环境中数据库只包含数百或数千个记录。当把应用程序转移到生产环境时，它可能需要从数据库获取数百万个记录，这会导致大量占用内存或应用程序停止运行，而且不报告错误。为了避免这个问题，程序员必须学会如何使用 FETCH FIRST xx ROWS SQL 游标语句。

Web 工作负载高峰常常比平均事务速率高 5 到 10 倍，所以会很快达到容量限制。为了避免容量风险，在开始应用程序项目时，应该问自己四个简单的问题：

应用程序要处理多少个 SOA 事务？应该做出这样的回答：“我们预期每天有 500 万个事务，包括 100 万次更新、200 万次插入和 1500-2000 万次页面查看。” 应该在获得足够信息之后，再做出回答。

服务器的硬件组件是什么？回答应该包含 CPU/核的数量、CPU 的速度、服务器涉及的内存分配以及网络连接的数量和速度。

使用哪些监视设施？在项目开始时就要获得性能报告，从而了解 CPU 负载统计数据和当前的网络通信量数据。

涉及哪些服务、服务器和数据库应用程序 DB2 包？因为 Java 应用程序通常使用动态的 JDBC SQL，所以很难跟踪应用程序的执行。应该向架构师和应用程序程序员索取应用程序执行图。了解哪些服务或进程可以调用哪些其他服务。当有人在夜里叫醒您询问 “数据库问题” 时，可以用这些服务调用信息帮助解决问题。

准备好适当的基础结构和监视信息。请记住，“数据库问题” 会导致用户离开。在 IDUG 会议（包括本月在 Dallas 举行的会议）和 IDUG.org 上可以找到更多性能提示。