从一开始就以正确的方式构建应用程序,它们就能够产生良好的性能。
来自 IBM Database Magazine 。
在因特网上,竞争的胜负常常在于 “一瞬” 之差。返回信息时的延迟就意味着丢失业务。因此,在开始设计应用程序时,就要考虑到性能问题。
在检查客户的应用程序和基础结构时,我发现的最常见的问题是为分布式 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 上可以找到更多性能提示。
- 本文从 IBM Database Magazine 期刊(原 DB2 Magazine)取得授权并进行翻译,参见 IBM Database Magazine 站点 上的 英文原文。
- 下载 DB2 V9 试用版体验 DB2 最新的技术特性。
- 通过访问 developerWorks 中国 Information Management 专区 的 DB2 9 技术资源中心获得更多的文章、教程和多媒体课件等学习资源。
- 通过访问 alphaWorks获得更多 IBM 的前瞻性技术和资源。
- 通过访问 IBM Database Magazine 站点 community 专题获得更多用户体验和交流信息。
![]() | ||
![]() | David Beulke 是 IDUG 的前主席、DB2 顾问、作家和演讲家,擅长数据库性能、数据仓库和互联网应用程序。 |
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/15082138/viewspace-534787/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/15082138/viewspace-534787/